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PR KPACP 


This I^rogram Verification Document details lh(* rt^sult^r of iho 
ASTI^ flight program verification sp(‘cified in the Program Ver ifical -n 
Plan for the ASTP Flight Program, IBM No. 7SW- 00005 and revised by 
75W-00032. 

The ASTl^ flight program verification effort was a complete 
verification. 

The independent simulator used in performing flight progr.im 
verification is an all digital simvilation utilizing an IBM System 370/ 
Model 155 Computer, The simulator program mathematically inorlels 
both ^he vehicle (6D) and the LVDC and is referred to as the 6D/LVDC 
simulator. A detailed description of the simulator is contained in 
Appendix B of the: AST^ Flight Program Verification Plan (PVP). 

Numerous support programs were used in verification by 
sumn-' ir izing data for rapid .an.ilysis and by making independent calcu- 
lations t(j aid m c'valuation of flieht program per fo>-mance . Some 
progran^s, where applicable, are duplicated on different computer 
systems to c*nsure accessibility rcgardU^ss of workload or machine 
dow'n time. A description of each support program is cfjntamer] m 
Appendix C of the PVP. 

One of the priniary ineans for d (dt'r mining the* ad(‘quacy of the 
flight program was by an analysis of the S-IVB end tonditiuns. Achie\<*d 
LVDC terminal end <'unditi(jns were caleulat(*d by an independent suppc/rt 
program for each performanc e case which reach(‘d S-IVB cutoff. I'lie 
achieved terminal end conditions w’ert? corn pa real a^jainst the rjesired 
terminal end conditions and the differences are listed in Appendix D. 
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SECTION 1 

GENERAI. VERIFICATION DESCRIPTION 



* 


1.1 INTRODUCTION 


This section contains a brief, general description of ASTI^ verification. 
The goal of the verification effort was to assare that the flight program, 
by meeting all mission requirements, will not be the limiting factor in 
achieving the mission, even In the presence of other vehicle failures. 

The discussion follows the outline in the Program Verification Plan for 
the ASTF Flight Programs (IBM No. 75W-00005). 

1.2 TYPICAL MISSION REQUIREMENTS 


The total program verification effort assures the accuracy and adequacy of 
the LVDC flight program and verifies that the final program meets mission 
requirements and conforms to program documentation. The results are 
also applied to guidance error analysis. 

Verification methods and results of the verification effort performed on the 
three mission phases (prelaunch targeting, boost-to earth orbit, and orbital 
operations) are discussed in the remaining sections of this document. 


1.3 


GENERAL FLIGHT PROGRAM REQUIREMENTS 


1.3.1 A pplicable Document List 

The documents used directly in verification of the ASTP fliuht pro ireim are 
listed in Appendix A. The specification document was the LVDC Equation 
Defining Document (EDD) for the Saturn IB Flight Programs (Reference 1), revision 
.1 JASTF^ mission), as modifiod by tlu- ASTP Thyht Pruyram Chaivo' R. c,u.-st- 
(rPCRs). Thi’ Asli-onics Systt-m Handbook (R i-lt-ronco 1 ) was ustrl durm<' vfr,lK.,- 

tion phases as an aid for intorprotation of tht- s|h-h 1 it. aliens , Tha I'r oi^r .uimio r ' s 
•Operating Manual (R t lorunce j) was ust-d to intoruret urotir.i mmma tt < hniquos . 

1.3.2 Program Functional Requirements 


The flight program’s functional requirements to integrate the guidance and 
control system with the launch vehicle sequencing system were verified 
directly by analysis of many special logic checks designed for this purpose 
and indirectly by the correct overall program response to nominal and 
numerous perturbed conditions (performance cases). Discussions and re- 
sults of the verification performed in each area are contained in the remain- 
ing sections of this document. 
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The program*s recurring functions through the mission are: 

• Navigation 

• Guidance 

• Attitude Control 

• Launch Vehicle Sequencing 

• Telemetry 

• Pro rammed backups to specific hardware functions 

• Command Processing 

• Data Compression 

Verification of these functions was accomplished in part by overall program 
performance, in part by special logic tests, and in part by specially designed 
independent digital programs (refer to Appendix C of the PVP) which analyzed 
flight program data. 

1.3.3 Requirements Interaction 

Verification of tiie interaction of function requirements was accomplished 
on every case run during the verification effort. Functions which require 
fixed repetition rates, such as the minor loop and the orbital guidance, were 
verified on special test cases. Other test cases, and performance cases 
which sequenced one-time events were checked to assure detection of each 
event within the specified time frame. To ensure that the variable repeti- 
tion rate is always consistent with accuracy requirements, plots were gene- 
rated showing each major loop con'iputation cycle Icngtli. Thiese plots were 
generated by the PLOTS portion of the SUPER support program for each 
performance case as described in Appendix C of the PVP, 

1.4 PROGRAMMING GROUND RULES 

Verification of adherence to programmed ground rule requirements was 
accomplished as outlined in the following ^ubparagraphs: 

1. Duplex computer (operation in the flight mode was checked by 
an independent computer program which ensured that the 
simplex/duplex mode selection bit was on in the operand 
address of each Change Data Sector (CDS) instruction and 

in each Hop Constant (HPC). Assurance that the flight pro- 
gram was initiated in the duplex mode of operation was ob- 
tained by decoding the HPC executed as a result of the CRR 
interrupt. 

2, Use of the Generalized Flight Program (GFP) concept and devel- 
opment of the GFP assembler have greatly minimizi'd the effort 
required to arid new requirements and delete old requirements. 
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Minimized verification effort and better quality control for pro- 
gram changes was achieved through development and uso of the 
symbolic tape conipare program described in Appendix C of the 
PVP, 

3. Verification of program variable scaPng was accon^iplished using 
two methods. Each time an accun'iulator overflow was executed 
within the 6D/LVDC simulator, all applicable data (instruction 
location, accumulator contents, etc.) was printed for subsequent 
analysis. All overflows were justified through analysis of the 
program listing. This verification method ensured that the 
assigned scaling can accommodate the maximum variable values 
experienced in both nominal and perturbed performance sin’iula- 
tions. Attainment of maximum accuracy and program efficiency 
was verified through a comparison of the simulated vehicle (6D) 
state parameters with those computed by the LVDC flight pro- 
gram. The difference in these parameters (navigation errors) 
was within the accepted mission tolerances in all pc rforrr'iance 
cases which had no perturbations to the inertial platform. The 
accuracy of the 6D is well established and thus provided an 
adequate check on the accuracy of the flight program parameter 
scaling. 

4. Corrc'ct implementation of the algorithms used to coniputo trig- 
onometric functions and the dot product routine was verified using 
the same methods described in subparagjaph (3) of 1 , 4 and by 
checking algorithm outouts after forcing particular known inputs. 

5. Flight Program listings were analyzed to ensure that all instruc- 
tions where various priority levels of interrupts could destroy 
or alter existing data are interrupt protected. 
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REFERENCE SYSTEMS AND TRANSFORMATIONS 


2.1 INTRODUCTION 

Several cooroinate systems and transformation matrices are defined for 
the Saturn IB mission. The verification accomplished to assure correct 
computation of the many geometrical relationships of these functions is 
discussed in this section. 

2.2 REFERENCE SYSTEMS 

The flight program correctly represents and uses all the various three 
dimensional vector functions mentioned in this section in solving the equa- 
tions of motion. Verification was accomplished by demonstrating the 
following: 

(a) The program has the ability to correctly establish an initial 
vector coordinate system from external input data for use 
as a reference. 

(b) The program logic is capable of properly executing the cal- 
culations necessary to transiorm vectorial parameters 
from one coordinate system to another. 

(c) The presettings used for vector component calculations are 
valid. 

Item (a) above was verified by the flight program initialization case described 
in Section 3. Items (b) and (c) were verified as described below. 

2.3 TRANSFORMATION MATRICES 

Vectors calculated by the flight program are correctly transformed from one 
coordinate system to another by operating on the known vector with the appro- 
priate transformation matrix. Verification of the transformation matrices 
are accomplished as discussed in the following paragraphs. 

2.3.1 [MSG] Matrix 

The [MSG] matrix correctly transforms vectors from the S- system to the 
G-system, Since the [MSG] matrix and the [MG4] matrix are multiplied to 
form the [MS4] matrix, verification of the [MS4] xnatrix (see paragraph 
2.3.6) indirectly verified the [MSG] matrix. 
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2.3.2 [MG4] Matr \x 

The [MG4] matrix correctly transforms vectors from the G-system t(> the 
4-system. See the discussion above for the [MSG] matrix. 

2. 3. 3 [mDS] Matrix 

This matrix is used in the acceleration profile computations in the simulation 
^light mode only. vSince this matrix is not used in the flight mode, no 
verification was performed. 


2. 3.4 [mbs ] Matrix 
a 

The [MBS^] matrix correctly transforms vectors from the B-systemto the 
S-system using the rotation through average gimbal angles. Verification was 
accomplished by ensuring correct backup velocity calculations and checking 
individual matrix elements. 

2.3.5 [M4V] Mat rix 

The [M4V] matrix correctly transforms vectors from the 4-system to tne 
V-system. This matrix is used to transform position and velocity vectors 
for terminal guidance calculations; accurate guidance end conditions (see 
Appendix D) and checking the individual elements verified the [M4V] matrix. 

2.3.6 [MS4] Matrix 

The [MS4] matrix correctly transforms vectors from the S-system to the 
4-system. Accurate guidance end conditions on each performance case 
(see Appendix D) verified the [MS4] matrix since this matrix is used in 
calculating position (1^^) and velocity (V^) which are used in the active guid- 
ance routines. Individual elements were checked to verify correct imple- 
mentation of the matrix. 

2. 3. 7 [MGA] Matr ix 

The [MGA] matrix correctly transforms vectors from the G-system to the 
A-system. Correct telemetry station acquisition and loss calculations 
and checking individual elements verified correct implementation of this 
matrix. 





2-3.8 [MSV] Matrix 

The [MSv] matrix is obtained by multiplying the [MS4] by the [M4 v] matrix. 
IGM parameters are calculated in the V-system as a function of navigation 
parameters in the S-system. Accurate guidance end conditions (see Appen- 
dix D) and checking individual elements verified correct implementation of 
this matrix. 

2.3.9 [meg] Matrix 

This matrix is not actually implemented in the flight program and therefore, 
verification is not required, 

2.3.10 [MES] Matrix 

This matrix is not actually implemented in the flight program and therefore, 
verification is not required. 
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SECTION 3 

PREPARE TO LAUNCH 


N75 33117 


3. 1 INTRODUCTION 

This section describes verification of the preflight prepare-to-launch/flight 
program interfacing, targeting load, and flight program initialization. 

Since there is no requirement in flight program verification to verify the 
error paths and logic implementation within the preflight routines, these 
were not verified. 

3.2 TARGETING LOAD 

The digital command system (DCS) is the primary method for loading tar- 
geting data into the LVDC. The target load command itself was not verified 
as it is used in the preflight mode only (see Section 10.4.12). The targeting 
load command was issued during all time periods of flight mode (boost and 
orbital) to verify that the command was not enabled by the flight program. 

A flight program patch was then used to enable the targeting load command 
during the orbital flight mode. A targeting load command was issued fol- 
lowed by a memory dump command to verify correct storage of the target- 
ing parameters. Correct utilization of the targeting load data was verified. 

3. 3 PREFLIGHT PREPARE-TO-LAU?;CH 

Verification of all of the requirements for computations and system checks 
described in this paragraph was accomplished using the bO/LVDC 

simulator. The ()D/LVDC ^innilator monitors «'ill error ind ic.' lions 
fron*i tlie pr epar c-to-launch routine and hcTts sequencing it erroTv^ 
exi St, 

3. 3. 1 GMT Synchronizing 

Real-time accumulation in the pre pare-to-launch mode was chocked by com- 
paring the value of accumulated time from the LVDC with the time in pre- 
oare-to-launch as computed by the 6D/LVDC simulator. The handling of 
this time as it is passed from the prelaunch rviutincs to the flight program 
was checked by a trace through phase I initialization. Platform gimbal 
angle readings made in prelaunch arc also passed over to the flight program 
and were verified in the same manner. 

3. 3. 2 Azimuth Laying Support 

Preflight azimuth con^iputations were verified by comparing the tclcmcterc*d 
azimuth with independent computations obtained using identical input quan- 
tities to both programs. 
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3.3.3 Variable Data Tape 

A ' isual inspection of the flight proeram listing was madr to verify lliat 
the specified locations are reserved for each parameter. The Uimiinal 
simulations run were made using the data on the variable data tape for 
the July 15 launch date. 

3.4 FLIGHT PROGRAM INITIALIZATION 

A program trace through phase I initialization was used to verify that Time 
Base 0 (TRO) was started properly, the accelerometers were read, the 
descending node of the desired orbit was calculated, and the remaining 
flight quantities were initialized. The trace verified that upon completion 
of flight program initialization, tlie LVDC/LVDA Firing Commit Enable 
Discrete Output (D012) was set and the boost mode calculations began. 

The MS4 and MSG matrices were verified as described in Section 2, 

' Maneuver angles from the variable data tape (patched to include all four 

quadrants) were traced to insure correct handling by the sine/cosine 
. rout-.ies during initialization. 
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SECTION 4 
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BOOST NAVIGATION AND GUIDANCE 


4. 1 INTRODUCTION 

This section discusses the effort involved to assure that the boost mode* 
of the flight program correctly provides navigation and guidance functions 
for the vehicle during periods when significant, measurable acceh*rations 
exist. Many test cases and performance cases were made, testing the 
ability of the navigation and guidance routines to properly compensate for 
several perturbations. Various plots of parameters of special interest 
were made on all performance cases, which facilitated a check on each 
calculation (each boost major loop) of these parameters. 

4.2 ACCELEROMETER DATA DESCRIPTION 

Each step in the processing of the platform accelerometer readings, from 
the read to the con^iputation of vehicle acceleration, was checked separately. 
Some steps were checked directly, by test cases, others were checked in- 
directly, by comparison to corresponding results in the 6D simulator. 

Each step correctly performs its function under both nominal and perturbed 
conditions. 

4.2.1 Accelerometer Data Format 

The flight program reads the inertial platform accelerometers and separates 
the obtained bit configuration into the A and B optisyn readings. The differ- 
ences between the current and past values for each reading, ^A and AB, 
are correctly computed and represent the measured velocity change during 
the last computation cycle to the nearest 0*05 m/s. Verification of the cor- 
rect program utilization of the A-optisyn readings was verified by hand 
computations on accelerometer test cases and by a favorable comparison 
(within accepted mission tolerances) betv'ccn 6D and LVDC navigation para- 
meters on all other cases. The B-optisyn readings were verified by simu- 
lating an A-optisyn failure and chcM king that the navigation paran-ictcrs 
continue to con^pare within accepted mission tolerances. 

4.2.2 A ccelerometer Data Processing 

The following paragraphs discuss the vcrific* tion accon’ifdishocl to assure the 
correct execution of the disagreement, zero and reasonableness tests on the 
velocity data changes. 
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4. 2. 2. 1 Disa^rf‘cm(?nt Test 

The disagreement test correctly selects the measured change (.'.A or Lh) 
closest to the expected change for zero and reasonableness testing. J.ogic 
tests which forced differences between thf‘ delta’s of -3, -2, -1, +1, -r2, 
and +3 in each axis, were run to verify that the proper channels were 
selected and that the appropriate mode code bits were set. 

4. 2. 2. 2 Zero Test 

The zero test correctly determines the acceptance or rejection of those 
velocity changes of one pulse or less depending upon time, vehicle attitude, 
and expected thrust misalignment. Special logic tests were run which 
forced AA and AB to be +1, 0 and -1 at times during boost when a zero 
change was acceptable and at times w'hen a zero change was unacceptable. 
Tests were also run w^hich forced ^A and AB to be +2 and -2 at times when 
a zero reading was unacceptable. Use of the zero readings and the backup 
velocity parameter for navigation purposes was verified by hand 
computations. 

The test which determines if the vehicle is within a 2° band of the plumb- 
line coordinate system axis was verified by chocking that the zero read- 
ings were accepted wh(‘n the expected changes w'er«^ l«*ss than A^o 
estimated uncertainty in the expected change computation due to thrust 
misalignments) and that the zero readings wc*re rcjecU*d when the f*xpec- 
ted change s wc*re greater than A^q and the zc*ro tc*st is enabled. Other 
tests were made involving outboard engine failures to verify proper changes 
to the parameter used in the zero test logic for expecte*d thrust misalign- 
ment (D. VSND). Mode Code 24 bits w'ere properly set for each case. 

Other cases w^ere run which monitored various parameter and "flag" change's 
throughout the mission to verify the bypassing of the zero test anel the 
additional zero test logic during the particular times specified in the 
Events Sequence Timeline table. 

There were no unexpected zero test failures in any of llu* cases simulated. 

4. 2. 2. 3 Reasonableness Test 

The reasonableness test correctly determines if the velocity changt- seh*cted 
by the disagreement and zero tests falls within a band of 450'’" of the e xpec- 
ted change en!arge‘d by a reasonableness test constant (RTC) multipli#*d by 
AT. Verifi .ation of the reasonableness t<*st w^as accomplishefl hy forcing 
the selected change to be j\ist within and just without the reasonable linuts 
for both increasing and decreasinc changes. Hand calculations were per- 
formed to verify the use of the backup velocity in place of the unreasonable 
changes. Proper bit settings in MC24 were also verified for each conrlition. 
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The RTC values are changed as specified in the Event Sequence Timeline 
table. This verification was accomplished by a scries of cases which 
monitor various parameter changes throughout the mission. 

There were no unexpected reasonableness test failures in any of the cases 
simulated. 

4. 2. 3 Velocity Accumulation 

The velocity accumulations in the flight program are correctly convt rt< d 
from pulses to platform velocity components 

case of accelerometer failures), from the backup acceleration param<*ter 
to platform velocity. Verification was accomplished by comparing actual 
(6D) velocity con'iponents in the platform system to the flight program 
velocity accumulations or, (in the case of accelerometer failure s, by hand 
computations . 

4. 2. 4 F /M Calculations 

The vehicle acceleration (F/M) is correctly calculated by dividing the root 
sum squart“ of tlu‘ difference' bet\ve(‘n the present and past vabu*s of 
Ym> ^^"m length of the pr(‘vious computation cycb . Verification 

was accomplished by comparing the actual (6D) F/M with the flight program 
F/M on all cases. 

During periods of flight in which the F/M computations may be unusually 
noisy, the preset constants for F/M arc used as specified in the Event 
Sequence Timeline tabic and the Presetting table. These F/M constants 
were verified by a series of cases which monitor various parameter changes 
throughout the mission. The accuracy of these presettings was verified by 
comparing the actual value of acceleration at thrust buildup to the preset 
value. 

4.2.5 M/F Smoothing Calculations 

The initialization of the smoothed reciprocal value of liiC measured vehicle 
acceleration (M/F) , and all of the independent variables used in the calcu- 
lation of (M/r)g, was verified by tlic cases which monitor parameters 
such as those for changes. The initialization value, magnitude and rate 
of change limits, and the time to start (M/F)^ calculations were verified 
to the specifications ip the Presetting table and Events Sequence Timeline 
table of the EDD. 

4.2.6 (F /M ) Acceleration 

Backup ac cele ra tin n (F/M)^, is co»*rectly romput(*d from prt* stored forct*. 
mass, mass flow* rate, and ro!nput(ul pe r fo rnuince Factor vahu*s. The 
precision of th(^ harkujj accele ration profile* was verifi(*d, via plots, by 
comparison to the actual atceleration profile for nominal flight. The 
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value of (F/M)^ flaring TBO and the spocifird values of force, mass, 
and mass flow rate used to compute the ba<'kup accele ration were vorifieri 
by the cases which monitor various parameter changes throughout the 
mission . 

The backup velocity is correctly resolved through the measured gimbal 
angles. Each component is used correctly for tlu* computation of the 
boost navigation parameters on all accelerometer failure cases. A 
failure was forced in each axis through all periods of boost with one* case 
for each axis to check the navigational accuracy of using the backup 
acceleration. 

The backup acceleration profile is correctly adjusted for S-IB engine 
failures. The backup force (F^), backup mass flow rate (M), and 
Performance Factor are adjusted by SIBEOB for the first detected S-IB 
engine failure. Verification was accomplished by a series of engine 
failure cases during different time segments, 

4. 3 BOOST NAVIGATION 

During boost, the flight program correctly determines the vehicle position 
and velocity relative to the plumblinc coordinate system (S-system). The 
following paragraphs discuss the effort to assure correct in>plenu*ntation 
of the trapezoidal integration scheme and the gravitational acceleration 
model used to compute^ these navigation parameters. 

4. 3. 1 Integration 

The trapezoidal integration scheme implemented in the flight program 
correctly determines the vehicle position and velocity from initial con- 
ditions, accel(?rometor data and earth gravitation. The basic tool \ised 
for verification of the boost navigation functions of the flight program is 
a comparison betwe*en the 6D and LVDC navigation parameters. The 6D 
uses essentially the same navigation equations that are specified for the 
flight program but has greater accuracy due to a faster integration rate, 
additional harmonic terms in the gravitation acceh‘ ration model, double 
precision floating point arithmetic, and the quantization level of the LVDC 
accelerometer readings (one pulse represents 0.05 m/s). 

4. 3. 2 Gravitational Acceleration 

The potential function of the earth that is used to model gravitational 
acceleration is correctly calculated during the boost periods of flight. 
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The same gravitational acceleration model is used for both the fli^lit pro- 
gram and the CD simulator. During the boost phase*;, the CD simulator, 
however, uses the third and fourth terms in the potential expansion wherea:^ 
the flight program, uses only the first two. The calculations for gravitation 
acceleration were verified indirectly by a favorable comparison (within ihc 
accuracy allovved) of the navigation parameters, 

4.4 BOOST GUIDANCE 

The flight program properly guides the launch vehicle to ihv desir<‘d 
orbital conditions by generating the necessary steering commands. 
Verification of the guidance functions was accomplished as discuss(‘d 
in the following paragraphs. 

^ First Stage Guidance 

The roll maneuver to align the launch vehicle along the specif i<“d azimuth 
and the preprogrammf‘d tim(‘ tilt guidance, including adjustments for 
engine failure's, are all executed properly. Verification of these functions 
is discusst'd in the following paragraphs. 

4, 4. 1 . 1 Roll Maneuver r 

The roll guidance con'imand is corr<‘ctly initialized to the last roll plat- 
form gimbal angle computed in the Prepare-to-I aunch routinf' (see 
Section 3). This initial command is held (frozen) until the vehicle has 
cleared the launch tow<*r (the vehiclt* has increased its position along 
the vertical plumbline (Xc^) axis GANTRY meters), or until the time from 
liftoff is greater than or equal to the specified time guard, at which time 
the roll guidance command is properly set to zerc. 

Verification of thi* corrt ^ : command at towi r clearance* and at the time 
guard war accon^plished. Proper setting of mode corle bits was verifit'd 
on all cases. 

4.4. 1,2 Time Tilt Pitch Guidance 

The time tilt pitch con'iputations begin under the identical requirements as 
the initiation of the roll maneuver. The initiation time was verified as 
discussed in the previous section. 

The pitch guidance command*^ during the first stage burn> w\ Ich are designed 
to yield a gravity term biased for expected winds, arc computed correctly 
as functions of time fron\ prestored polynomials. rh(‘ 6D/LVDC simulator, 
which has the capability of simulating the expected winds for 
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the specified launch month, was us(*d to ve rify t’l j)itch commands, 
j From the initiation of time tilt pitch guidance until the tilt arrest time, 

the guidance commands in tlic minor loop were' r-c>mpaiu-d a^aiiibt a Linu 
tilt pitch profile?. The two compared wdthin the* specified tolerance*. 

4. 4. 1. 3 Time Tilt Yav. Guidance 

The yaw guidance commands are correctly compute*d from tables as a 
function of time (T^). For this mission, the yaw' table* is set to zero. 

The yaw table logic was verified by inputting known tables and indepen- 
dently solving equation 4. 4. 2. 1 (Refere*nce 1) v/ith these know'n tables, 
ensuring that the yaw command profile? was w'ithin a specified oand of 
the tabular profile. 

4. 4, 1. 4 Engine Out Guidance Modifications. 

The guidance commands are correctly adjusted for S-li^ e*ngine* failure*s. 
Verification was accomplished by a series of engine* failure* cases durini; 
each segment of the* engine failure fre.*e‘Ze time* function and during e*ach 
segment of the* tilt arrest tirrie* bias function. Propf*»* engine out de*tect- 
ion, adjustme*nt s to the backup acceleration ^F/M)^, mode* code* bit 
settings, and adjustments to D. VSND were* also ve*rifie*d. 

I 4.4.2 Iterative.* Guidance Nfode* (IGM) 

i 

Correct imple-mentation of tlie active* guidance scheme in the flight pro- 
gram was v"erified as discussed in the followiiig paragraphs. 


4. 4. 2. 1 General Description of IGM 

The IGM scheme correctly performs its two general functions: IGM guidance 
computation and IGM phasing. Roth functions arc dependent upon numerous 
variables, most of which change considerably with v^ehicle perturbations. 
Consequently, the guidance scheme was verified indirectly by looking at the 
overall program performance. The basic verification tool used to analyze 
overall program performance was a set of plots including all significant 
intermediate IGM parameters, all phasing parameters, and all guidance 
paranieters for each performance case. The graphs were plotted by com- 
puter as a function of time from GRR and contains one value for each com- 
putation cycle. 

The paran\eters listed in the P\'P were plotted for IGM analysis for each [:>er- 
formance case. Definitions of the parameters are covered in tlie HDD. 

The plots of these parameters w'ere analyzed by an examination of their cor- 
responding mathematical equations (see Section 13 of the EDO), Each inflec- 
tion point, '’spikt ,” or otiier unusual action of the parameter was explained 
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by checking fchat it reacted in the manner dictated by the appropriate equation. 
The effects of IGM phasing, artificial tau modes, thrust level changes, and 
performance perturbations on each parameter were studied to ensure proper 
response. 


4, 4. 2. 2 Basic IGM Guidance Calculations 

The IGM guidance commands required to steer the vehicle into the desired 
orbit are calculated correctly during each computation cycle. These guidance 
commands were checked by a very close critique of some of the aforementioned 
plots. 

All preset guidance parameters (those winch are assigned an initial value) are 
initialized correctly. These presettings were verified by observation on the 
nominal and/or performance cases or by the special cases which check various 
parameters for charges throughout the mission. 

The fin^il test of the accuracy of the guidance calculations is evidenced by the 
close agreement of the achieved (LVDC) terminal conditions on all performance 
cases to the desired conditions (see Appendix D), 

4, 4, 2. 3 Basic IGM Phasing 

IGM phasing calculations ?nd logic properly determine what parameters repre- 
sent vehicle performance and correctly sequences IGM calculations. The ini- 
tialization of the smoothed reciprocal value of the measured vehicle accelera- 
tion, (M/F)g, and all of the independent variables used in the calculation of 
(M/F)s were verified by the cases which monitor these parameters. The 
initialization values and the times to start (M/F)g calculations properly 
conform to the specifications in the Presetting table and Events Sequence 
Timeline table of the EDD. 

^GM phase initiation times, mode code bit settings, artificial tau phasing, 
X-steering initiation time, and the high speed loop initiation time are all exe- 
cuted properly. Verification was accomplished by close observation of the 
applicable data printed each computation cycle on every 6D/LVDC performance 
case. The effects of all the above phasing on the total IGM guidance was 
checked on each performance case via plots. 

4. 4. 2, 4 Terminal Steering and Cutoff 

The inUiation time of \-stcering and the zeroing of the position correction terms 
during X“Steering was verified on each performance case. 
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The S-IVB cutoff prediction correctly enables the vehicle to attain the 
velocity required for injection into the desired orbit. The calculations 
for and the issuance of the S-IVB velocity cutoff command in the high 
speed loop were verified on the performance cases by checking the exact 
time of issuance of the S-IVB velocity cutoff command in the high speed 
loop were verified on the performance cases by checking the exact time 
of issuance of the switch selector command. An independent program, 
which uses flight program position and velocity data from the high speed 
loop and the S-IVB cutoff switch selector command time, calculated the 
achieved cutoff velocity by extrapolation. This velocity compared favorably 
with the desired cutoff velocity on all performance cases. 

An additional check on the S-IVB fine cutoff prediction scheme was accom- 
plished by a comparison of the achieved terminal conditions with the desired 
terminal conditions. These conditions are derived by extrapolating the 
state vector (radius and velocity components) at cutoff to the time that t».'r- 
minal velocity is reached considering the velocity bias (AV^) for thrust tailoff. 
The differences are shown in Appendix D and the close comparison irxdirectly 
verifies the adequacy of the fine cutoff scheme. 

The start time of the high speed loop (HSL) was verified on every performance 
case considering the time bias AT^^. The velocity guard logic for the high 
speed loop was verified by program trace. 

4. 4. 3 Guidance Reference Failure (GRF) 

Guidance reference failures were forced in several cases to verify that D04 and 
D06 are set, bit 14 of Mode Code 27 is set, attitude error commands are frozen 
and DI9 (spacecraft control of Saturn) is checked. After DI9 is set, the program 
zeroes the attitude error command and sets bit 1 5 of Mode Code 27. 


Special GRF cases were run forcing a GRF prior to and diiring the high 
speed loop (HSL) to dexronstrate the following: 

• In response to a GRF before HSL initiation, entrance to the 
HSL was inhibited and DI9 tests were enabled. 

• In response to a GRF during the HSL, the GRF was recog- 
nized, and the HSL continued until cutoff. 

4. 4. 4 Steering Misalignment Correction (SMC) 

The steering misalignment correction (SMC) properly compensates for 
errors caused by the misalignment of the thrust vector with the vehicle 
longitudinal axis. The calculations for the SMC terms were verified by 
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hand calculations made at various points in the flight (where SMC compu- 
tations are active). Good terminal conditions on the nominal and the 
performance cases indirectly verified the SMC calculations. 

The correct setting and resetting of bit 10 in MC25, the nominal sequencing 
of the SMC computations, and the inhibiting of SMC computations for pro- 
gram limiting and active hardware failures are performed correctly. 

4. 4. 5 Chi Computations 

Steering commands (Xy4 and computed in IGM are properly converted 

into the platform gimbal system and the SMC terms are correctly added to 
the guidance commands. Assurance that the yaw command is limited to 
a maximum magnitude of 45^ was obtained by a special trace of program 
logic. 



I i 


SECTION 5 N 75 33119 

ORBITAL NAVIGATION AND GUIDANCE 
5. 1 INTRODUCTION 

This section describes the verification performed for the following orbital 
functions: 

• Orbital flight mode initialization 

• Orbital navigation 

• Orbital guidance 

• Telemetry acquisition 

Verification of other orbital functions is discussed in the appropriately 
named sections. 

5.2 ORBITAL PROCESSING RATES 

The flight program's ability to accomplish the processing required for each 
orbital function at the specified rates was verified utilizing the output from 
the 6D/LVDC simulator. The minor loop and minor loop support cases de- 
scribed in Section 8 were used to verify correct implementation of the timing 
logic for these two modules. Once this was accomplished, only the time 
controlling constants used by these modules required further investigation. 
Simulations made across each area of constant replacement were used to 
verify correct processing race control for the minor loop and minor loop 
support modules. The execution rate for orbital guidance computations 
was verified using 6D/LVDC simulator data. These cases were also used 
to check the processing rates for position extrapolation, orbital navigation, 
discrete processing, gimbal angle read, and telemetry acquisition and loss 
determination. Verification of these cases was preceded by a flight pro- 
gram coding check to ensure that the guidance and navigation parameters 
are telemetered when computed. Event sequencing and interrupt processing 
during orbital flight phases were indirectly verified ])y the minor loop cases, 
a check on correct switch selector command issuance, and the DCS interrupt 
tests described in Section 10, Adherence to the Event Sequence Tin'icline in 
Reference 1 was ensured for each orbital function, 

5. 3 ORBITAL INITIALIZATION 

Proper parameter initialization for orbital navigation calculations was veri- 
fied by analyzing a program listing and by utilizing the na\igalion error 
computation features incorporated m the uD/LVDC .simulator. The 
differences !)elween tlie flight proL’ram comput<‘d values and the parallel 



5-1 



T 


f 


and independently computed program values were printed for (^ach 
computation c ycle. Plots of the error functions across the orbital 
initialization period were used for detection of possible (‘rrors in 
navigation componen: initialization and scaling. 

5.4 ORBITAL NAVIGATION 

Implementation of the orbital navigation scheme was verified using the ct:>n- 
cept that if the end result is good, then all of the individual cons ider atiems 
arc correctly accomplished. However, a flight program trace of the 
applicable modules was used as an additional means of validating the 
computations employed in the orbital navigr-ang scheme. The 6D/LVDC 
simulator compared ^he navigation param ter calculations of both 
computing systems as described in paragraph 5.3. Analysis of this 
data yields an accuracy figure for each flight phase. The 6D simulator 
was thus the reference against which the flight program implementation 
was checked since the accuracy of llie (dl is well established. The follow- 
ing paragraphs discuss the applicable > n simulator’s program areas used 
for orbital navigation verification. 

5.4.1 Integration 

Integration of the equations of nn;tion \vit}‘ n the 6D projjram was accomp- 
lished at the end of each flight proei -i* nuncrloop resulting in navigation 
parameter update approxi’ ately every iOO milliseconds in the orbital 
flight phase. The digital integration is a forward trapezoidal scheme. 

Use of this ’nle<:ration rate provides an accurate reference for compari- 
son to the fliuht program scheme of na’ i eat ion parameter update every 
eight seconds utilizing a midpoint preduiur in a modified Scar bor ougli 
technique. 

5. 4. Z Acceh^ration Models 

The mathematical models used to compensate for the effects of gravity and 
drag accelerations on the vehicle are identical in botli the 6 0 <md flight pro- 
grams for orbital simulation periods. Since the oD model implementations 
have bet*n proven, only the input data needed further in\ estigation. 

5.4.2, 1 Gravitational Acceih^ration Model 

The equalions for ilie j. ravitalion acceleration model require- vehicle posi- 
tion components as inputs. Since these v'aliu's are computerl iiy the nO sim- 
ulation, no further verification was r(‘quired. 

5. 4. 2. 2 Drag Acceleration Model 

The equations for the drag acceleration modcT use input ]>aranu‘tc‘r s ( om- 
puted within the simulator. No verification effort was required m this .irea. 
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S. 4. 3 Naxiyation Update 


At the specified na\ieation update tune, TCHNI-PTIM, of e\ery acre})t(*d 
DCS command, th(‘ established processin-' seqiu’ncc* was corr(.*rtiy ])ct- 
formed. Subsequently, the guidance passi's and ilie na\i<jation passes 
were scheduled at one and eiidil second intc»rvals, r c s pect i \ ely , after 
the spec ified na\ic;ation update execution time, Vc* ri fi cation c:>f the navi- 
gation update capability is also discussed in Section 10. 

4, 4 Delta V Monitor imz 

An accelerometer error input to the OD/LVDC simulator was used to 
cause the desired acceleration to be read each time the accelerometers 
arc read in Time Base 4 and Time Rase 5. The trace capability of the* 
OD/LVDC simulator was used to verify that the accelerometer data w'ns 
processed correctly. 

5.4.4. 1 Delta V Monitoring During Time Base 4 

During Phase II Initialization, the miuasured elocity components arc‘ ^et 
to zero and thc‘ accelerometers are read. The' a cce] cu* omete r s are read 
each second thereafter and the; change in the mc*asurc‘d elocity is accu- 
mulated in the storage locations dcsignatc*d lor the* measurevl elocity 
components. The \'elocity components are lelenu*te*r ed each tinie the 
accumulations are made. The velocity is accurnulat erl from \he "A’’ 
channe'l only for each of the three a c c elc‘r omet e r s . Xo disagreement, 
zero, nor reasonableness testing was performed on the ac c eder omet e r 
data and tlu- data was not used for na ■ igation during tliis lii^ie period. 

5, 4, 4. 2 Delta V Monitoring During Time Base 5 

At T“+0,0, tile measured \cTucity components are reset to z(;ro and thr 
accelerometers ar(; read. The accelt; romet er s are not read agairi vintil 
T^ + 31.0 seconds, but are rt'ad e'>ery second tlu‘r eat t er . Delia \' Moni- 
toring proci^ssing in I'lme Base ^ ineludes all the* prcuessing dc)iie ’n 
Time '^jase 4. If Tune bist; has started, a t(‘st is made on DKL.VR. 

If DELVR is zero, no further action is teiken on tltat pass; but if I)FL\dv 
IS non-zero, the total ( Itange in measurerl ' elcu ity is calculated by taf - 
ing the square root of the sum of the squares of the elocity (omponents. 
When the total change in the measured \ elocity ccoines greuater tlia^ or 
equal to DELVIM fhe safing sequence is initiated. lEgLYR is set ; ' "o 

wh(;n the safing S(‘quence is started, regardless of the c ondition midc*r 
which the safing sequence is starred. 

Delta V Monitoring was verifier! ii. < onjurction witli tlu' S-I\'B/IIJ Dc'- 
or,dt DCS Commanrl, Section 10.4. 13. 
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5. 5 ORBITAL GUIDANCK 

Vehicle attitude control durinL’ orbital flight period was verified usinp, tlie 
outputs of the An/lAM^r sin'mlator. Attitude computation rate verification 
is covered in paraura])h S.2, Each of the four basic maneu\er types was 
thoroughly exercised ind i\ irlvially and a series of mancu\(jr combinations 
executed to test for possible undesirable interaction. Preprogrammed 
maneuvers were checked for correct initiation and termination in each 
nominal simulation. Nominal cases were designed to include all the 
programmed maneuvers defined for i>ie mission. Perturbations to the 
nominal attitude timeline were designed to test all realistic maneu\er 
combinations of preprogrammed, DCS, and spacecraft initiated vehicle 
attitudes. Mode Code indications and guidance commands were monitored 
in each simulation to verify correct implementation. The following para- 
graphs describe the verification requirements applicable to each maneu\er 
type. In all cases, the computed \ehicle attitude derived from the platform 
gimbal angles was checked to ensure that vehicle control was within the 
control system (APS) deadband. Time Base 5 was started during each 
l-ossiblc maneu\er type to \erify that maneiuer in progi s is maintained 
w’hen the new time base is initiated, 

5. 5, 1 X -I'reeze Maneiuer 

Proper command liolding of the last computed value during each X«freezc 
maneuver was verified through analysis of tlie chi components printed for 
each pass of the OD/LVDC simulator. 

5,5.2 Inertial Attitude Hold Maneuver 

Verification of the inertial hold maneiuer consisttd of ensuring that the 
specified angles in the platform coordinate system replaced the X commands 
upon maneuver initiation and that the commands were held constant until 
the next maneuver. Gimbal angle rate of cluangc and attitude response* 
time were also analyzed, 

5. 5, 3 Track Local Reference Maneuver 

The guidance commands computed for each track local reference maneu er 
were verified using an independent computer program. Tins guidance clieck 
progran-i uses flight program computed na\igation and guidanc e parameders 
to calculate and print the vehicL' attitude offset from a plane parallel with 
the local liorizontal. Possible attitude computation errors are easily 
detected using this program. 

5 , 5 , d Inertial Hold of Local RefercuiiO ManeiCver 

The trade local reference guidance check progratn was used to \<‘rily that 
tie flight program c orrectly computeci the guidance c oinnuands at inaneu\er 
initiation, Fmsuring that these guidaiue commands are held constant for 
the duration of the maneu\er \erifies tl at the* maneuver is implemented 
properly. 
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5. 5. b Control S\vitc ho\er C apalnlily 

Simulations wore made across T 134 with D19 on to oiihure that the lliclit pro- 
grani lo^ic checks for the sparerralt (S/C') control inrlitation as a liuiction 
of the ”S/C Control of Saturn Fnahle" switcli selector comniUnrl, Interaction 
of the S/C control capability with other orbital maneu\ers was tesleri throucli 
a series of bO/LVDC simulations, S/C control was taken and returned across 
and durine each maneuver in the nominal attitufie timeline. I^erturbed maneu- 
ver comlnnations are also tested for all realistic confii^urations. S/C f ontrol 
was also taken and returned after an Tcxecule Generalized Maneu\er DCS com- 
mand was received but before implementation. All combinations of setting 
and rescttini: DIO with the "-rious maneuvers possible with the PTxerute Cicn- 
eralized Maneuver DCS command were verified. PGi.dit proeram response 
was correct for each combination of rnanc-uver and DT* c ».>ndition. 

Correct attitude calculations upon vehicle return of control to thi? ID were 
verified in each case usinu the guidance parameters telemetered in conjunc- 
tion with independent calculations. Mode Code 27 indicator bit implementa- 
tion was checked, 

S, 5, () Guidances Reference Ik^iluri* (GRPp 

Attitude command modifications as a function of C3IM' detection anrl S/C con- 
trol (DI‘^) was verified in a tc'st s(‘ries designed to clieck program perfor- 
mance in cvach time l:>ase and flijht mode. Assurance that the lachicr com- 
mands are frozen upon detection of F anri zeroerl vvlun DF^ is detected 
was obtained by a prouram trace* of the louic . Atten'ipts to chance the* larl- 
der coiTimands was acccjmplished by issuance of I7CS navigation u})dates 
with suitable parameters, 

5. b. 7 DCS Commanded I'unctions 


Verification of the I^C^S commands capable of altcrinu the nominal attitude 
timelines is described in Section 10, 

^•5.8 Variable Data Tape Mamurers 

The start times for maneuvers 4, n, and 7 and the attitudes vvitli rc‘^p<*ct 
to local horizontal and the desired roll ancle {or manc-ir c*rs 4 and ♦» are 
obtained properly from the locations defined for tliese parameters on the* 
variable data tape. The snap and trace capai)ility of tiie vD/LVlK' simula- 
tor was userl to erify that the data was obtained from the* ariable data 
tape locations and in^.ph‘im*nted correctly in the orbital guidance calculations. 
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TELKMKTRY ACQUISITION AND LOSS 

The program correctly cletorn^incs the launcli \ chicle position with 

respect to the earth oriented telemetry receivinu stations. Simulations 
of four re\olutions were made at the nominal launch azimuth. 

^0^.1 Acquisition and J^oss Calculations 

The acquisition and loss calculations correctly determine whether or not 
the vehicle is in ranjje of a telemetry station. These calculations wen* 
verified by comparing the telemetered acquisition and loss times auainst 
the results of an independent program, 

5.6.Z Acquisition and Loss Sequence 

The alternate switch selector sequences required lor the mission were 
shown to be correctly commanded through analysis of telemetry data ob- 
tained from the simulations. 
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SECTION 6 


There is no requirement for Section 6. This section is included to be com 
patible with the Saturn IB EDD. 
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oECTION 7 


N75 33120 


TIMK TRASKS, DISCRETES, AND INTERRUPTS 


1. 1 INTRODUCTION 

This section discusses the effort performed to assure proper flight program 
handlinj:^ of time bases, discretes, and interrupts. 

7, 2 TIME BASES 

Time bases are used to conveniently reference fli^ht program events to some 
key mission event. Proper initiation of all time bases by recognition of tht* 
primary signal as well as the backup signal was verified as outlined in the 
following paragraphs. As an assurance that time bases are initiated only 
within the corrc'ct time frames, each primary and backup signal was force d 
prior to the time base enable* time and forced again just after the time* imse 
initiation time*. Each tin^e base* initiation tiim^ was verified by clif-cl:ing tliat 
TI was updated to within 2 ms of the ti:ne tliat the flight program recognized 
the required signal(s) for starling the tin^e* base. 

7. 2. 1 Time Base; 0 (C uidancf* Uef(*rf*nr e Rc^lease ) 

TIU) is correctly initiated by the CRR interru])t (IN'I'T) from the launch 
sequencer. Verification of the proper initiation of TBO was accon'iplis hed 
by sequencing the flight program through the preflight routines and checking 
that, in response to 1NT7, thi' time in the* tin'll* base (TB) and the time of 
time* base initialization from GRR (TI) were initialized correctly, that the 
correct mode code bit was set and that pliase I initialization was perfornw d 
as specified In the Evi*nt Sequence Timeline table and the Presetting tabli . 

7, 2. 2 Timt * Base 1 ( Liftoff , 

TBl is used for st*quencing during S«1B stage until detection of the 
low leve*l sensors dry interrupt. 

% 

TBl is initiated properly by receipt of either liftoff discrete (DI7 or DI24). 
Failure to liftoff (by inhibiting D17 and DI24) v.*as si quenced to verify correct 
program action at T041S0. 

Correct monitoring of DIT and D124 was ve rified by st lling each indt i)endt ritly 
and together prior to tiu* enable time and utilizing a prograi'n tract* to deu.c^n- 
strate that each is cht*cki*d propt*rly from Uie -nable tim* until TBl. Prope r 
initiation of 'FBI was verified b^ demonstrating tlual TB and 'll are corrt-ctlv 
updated, that Iht* proper mode code bit is sc*t and that 'klU evt*nts ar * executt d 
as specified in the Event Sequence Timt*lint» table. 
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7.2.3 Time 2 (S-IU I.o v/ Lc,-v(-l St-ns ors Dry ) 

TB2 is used for sequencing from S-ll^ low level siuisors dry until S-IH 
outboard engine cutoff. The signals for initiating this time base are ^he 
S-IB low le*vel sensors dry *'A” interrupt (INT2) and the S-iB low lf‘vel 
sensors drv "B" interrupt (INT6), Correct initiation of TP)2 was verifir*d 
by checking the program's response to INT2 and INTf), Fach interrupt 
was inhibited to verify corr<‘ct initiation of the time base by rec(dpt of the? 
other signal. Both INT2 and INTh were set prior to TB2 enable to verify 
that TB2 is enabled properly. 

Verification of the downrange velocity constraint was accomplished by 
forcing the downrange velocity to be less tlian 500 m/s and checking that 
TB2 was not started and the program set the ladder outputs to zc-ro and 
entered a one-instruction loop. Correct bypassing of the velocity con- 
straint was verified by starting TBl without actually lifting off, forcing 
GRF, and demonstrating that TB2 wa^ pr»-periy inUiated. 

2* ^ Time I^ase 3 ^S-TB Ou tb oard F ngines Ct^toff) 

TB3 is used for sequencing during stage- d'he prin^ary signal for 

initiating the time base is the S-IIi outboard engine s cutoff ”A ' interrupt (1X7 5) 
and the backup signal is the S-IB outboard engintus cutoff "B'' discrete 
(DI23). 

Correct initiation of TB3 by the primarv Signal was verified by checking the 
program's response to INT5. INI’S was inhibiti-d to verify correct initiate 
of the time base by receipt of DI23. Both INT5 and DI23 were set prior to 
TB3 enable to verify that Tli3 was enabled properly. Also, both IN 7’ 5 and 
DI2 3 were inhibited, T1^3 was properly initiated on the time backup at tlu‘ 
correct time by the flight program. 

7.2.5 Time Base 4 (S-IVB Cutoff) 

Tin'ie Base 4 (T134) is used for sequencing after S-IVB cutoff, 'rhere are four 
indications which are checked to start TB4; the detection of any two of which 
will initiate the time base. These four indications are listed btTow: 

• S-IVB Engine Out "A" (DI5) 

• S-IVB Engine Out ’TV’ (INT4) 

• S-IVB Cutoff switch selectcjr issued by the L\'OC 

• Velocity change of U'ss than 1 m/s rTu*aiure*d by th.e 
inertial platform over last boost major loop 
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Verification of the proper initiation of TB4 was accomplished by forcing 
inhibits on all combinations of these four conditions and checking that, in 
response to at least two of the conditions being present prior to TB4 
enable, the proper mode code bit was set, TB and TI v\^ere correctly up- 
dated and the TB4 events were executed as specified in the Event Sequence 
Timeline table. Single indications were forced to verify that initiation 
of TB4 requires two S-IVB r jto^f indications. 

Time Ease 5 (S-IVB/IU De-orbit DCS Command) 

Time Base 5 is used for sequencing of LOX and dump, and a vehicle safing 

sequence* Time Base 5 must start at IM+bOTj^gg, where is specified by 

a DCS commando To prevent premature starting of TB5, it must be inhibited 
until T4+T5 _^t-.* 

Proper initiation of TB5 was checked by issuing Tj^gg to start TB5 prior to and 
after TB5 is enabled* In the former case, the DCS command was rejected by 
the flight program, and a DCS error code issued. In the latter case, proper 
response was verified by observing that bit 7 of Mode Code 27 was reset after 
being set by the DCS command, DCS time updates were also issued to ensure 
that they did not affect the Time Base 5 start time. 

7. 3 DISCRETE OUTPUTS 

Discrete outputs are directly dependent upon the flight program and are used to 
affect external equipment. Of the thirteen bit positions in the discrete output 
register, only five are used inflight. The proper setting of these discrete 
outputs was verified as discussed below. 

7. 3. 1 DPI: Reset Command Decoder 

This discrete output is an indication to the command decoder that a DCS word 
has been read and found to be valid by the flight program. Issuance of this DO 
provides a computer reset pulse (CRP) that resets the command decoder. The 
correct setting of DOl was verified by demonstrating that, in response to a 
valid DCS word, the DO is set to a logic 1. Invalid DCS commands were issued 
to verify DOl remains a logic 0 in response to rejected commands. 

7*3,2 D04 and D06: Guidance Reference Failure 

D04 and D06 are redundant indications of guidance reference failure (GRF). 
Verification of the proper setting of these discrete outputs was accomplished 
by demonstrating that D04 and D06 are set to a logic 1 in response to a GRF. 

7. 3. 3 D012: EVDA/LVDC Firing Comrrat Enable 

The flight program sets this discrete output to signify a ready-to-launch condi- 
tion after receipt of GRR* The correct setting of D012 was verified by demon- 
strating that the DO is set upon completion of normal flight program initializa- 
tion and is reset at Tl+0. 
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7. 3. 4 DQ13 ' LVDA/LVD C Firing Commit Inhibit 

This discrete output is interlocked with the launch sequencer such that its 
receipt forces a countdown recycle before launch is possible, DO! 3 is 
set by hardware, not by the flight program. 

7.4 DISCRETE INPUTS 

Discrete inputs are hardware dependent signals originating outside the flight 
program which control flight sequencing fiinctions by affecting program flow. 

The flight program’s response to each signal was verified as outlined in the 
following paragraphs. 

As an assurance that the discretes are honored only in the proper time frames, 
each discrete was forced in the following internals: 

• Before the discrete is enabled 

^ After the discrete has been detected 

• After the discrete has been disabled 

The correct sampling rate of the discrete input register (DIR) was verified uti- 
lizing the selective print capability of the 6 D/IjVDC simulator. 

7.4.1 Dll: RCA-llOA Sync 

DU is used only in the ground routines and there is no requirement for the flight 
program to monitor this discrete. Verification that Dll is never monitored was 
accomplished by activating DU during several phases of the mission and check- 
ing that no program reaction results. 

7.4.2 DI2: Command Decoder OM/D ”A" and Command Decoder OM/D 


This discrete correctly indicates to the LVDC whether a DCS coiumand is a mode 
or data command. The corr^-ct program response to this discrete w^as vc^rilied 
by issuing a DCS command and demonstrating that the program sets up for a 
mode command in response to DI2 being a logic 1 and se ts up for a data command 
in response to DI2 being a logic 0. 

7.4.3 DI3: Sparc 

DI3 is a spare and was not monitored by the flight program. Verification was 
accomplished by forcing the discrete during several parts of the mission and 
checking that no program reaction occurred. 


A 
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7o4a4 DI4: Spare 

Verification was the same as for DI3. 

7.4o5 DI5: S-IVB En^^ine Out 

DI5 indicates that the S-IVB engine is out and is one of the conditions which ini- 
tiates TB4. The correct program response to this discrete was verified by 
forcing the discrete and utilizing a program trace to demonstrate that the 
presence of DI5 is noted as one of the conditions for starting TB4. DIB and 
each other condition for starting the time base were forced to verify all logic 
paths. 

7. 4. 6 Dl6: Spare 

Verification was the same as for DI3 

7.4.7 DI7: Liftoff ^^B»» 

This discrete indicates that liftoff has occurred. The proper program response 
to DI7 was verified by demonstrating that TBl is initiated by recognition of 
this discrete. A program trace was used to verify that D17 is detected within 
the specified time. 

7.4.8 DI8: Spare 

Verification was the same as for DI3. 

7.4.9 DI9: S/C Control of Saturn 

This discrete is a signal from the spacecraft to indicate to the LVDC that the 
spacecraft has taken control of the flight control computer (FCC) and that the 
LVDC outputs to the FCC are not being accepted. Correct program response 
to the presence of this discrete was verified by forcing DI9 and demonstrating 
that the proper mode code bits arc set and that the ladder outputs are zeroed 
by maintaining the and minor loop X’s equal to the gimbal angles and by 
setting the minor loop X rates to zero. The correct interrogation of this dis- 
crete by the flight program was verified by using a program block trace to 
demonstrate that DI9 is monitored once per BML from T4-f 5. 0 seconds to 
orbit initialization and once per second from then until T5+0, Verification 
of the detection of DI9 in combination with a GRF is discussed in paragraph 

5. 5,6. 

Verification of the correct program response to the deactivation of DI9 is dis- 
cussed in paragraph 5. 5. 5. 
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7.4.10 DUO: Coolant Thermal Switch #1 


DUO and Dill indicate that the temperature of the environmental control system 
(ECS) coolant is above the selected control temperature. The verification of 
the correct program response to these discretes was accomplished by settii.^ 
and resetting combinations of DUO and Dill at various times during the flight 
and checking that the proper switch selectors are issued. 

The correct sampling rate of DUO and Dill was verified by demonstrating that 
these discretes are checked every 300 seconds beginning at TO+TM seconds. 

Correct inhibiting of the water control valve logic was verified by demonstrating 
that DUO and Dill are permanently ignored by the flight program following the 
Water Control Valve Logic Inhibit DCS command and that bit 18 of MC27 is 
reset. 


7. 4. 1 1 Dill: Coolant Thermal Switch #2 

See Dll 0. 


7.4.12 DI12: S-IB/S-IVB Separation 


This discrete indicates that the S-IB and S-IVB stages have separated. There 
is no requirement for the flight program to monitor this discrete. Verification 
that DI12 is never monitored was accomplished by checking that no program 
reaction results when DI12 is reset. 

7.4.13 Dll 3: Spare 

Verification was the same as for DI3. 

7*4.14 Dll 4: S-IB Outboard Engine Out 


This discrete indicates that at least one S-IB outboard engine is out. Correct 
adjustments based on the detection of DI14 in TBl were verified by forcing an 
S-IB outboard engine failure and checking that the tir .e tilt calculations were 
properly modified, that the backup acceleration, (F/M)^, was correctly ad- 
justed, that the correct mode code bits were set and that SIN(6®) was substi- 
tuted for SIN(2®) in the zero test computation. Correct adjustments based on 
the detection of DIM in TB2 were verified by forcing an S-IB outboard engine 
failure and checking that SIN(6®) was substituted for SIN(2®) in the zero test 
computation, and that the proper mode code bits were set. Verification that 
erroneous indications of an S-IB outboard engine failure are handled properly 
was accomplished by demonstrating that, in response to forcing DIM without 
an engine failure, the discrete is detected the same as for a valid S-IB out- 
board engine failure. A program block trace was utilized to verify that this 
discrete is checked once per BML, until detection, during the time interval 

from Tl+T_,_^ seconds until TB3. 

SlEO 
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7.4.15 DII5: S-IB Inboard Engine Out 

Dll 5 indicates that at least one of the S-IB inboard ^^ngines is out. Correct 
program adjustments based on tlie detection of this discrete in TBl were veri- 
fied hy forcing an S-IB inboard engine failure and checking that the time tilt 
calculations were properly modified, that the backup acceleration, (F/M)^, 
was correctly adjusted, that th^ correct mode code bits were set and that 
SIN(6® ) was substituted for 5111(2^) in the zero test computation. Correct 
adjustments based on the detection of Dll 5 in TB2 were verified by forcing 
an S-IB inboard engine failure and checking that SIN(6^) was not substituted 
for S1N(2°) in the zero test computation, and that the proper mode code bits 
were set. 

Verification that erroneous indications of an S-IB inboard engine failure are 
handled properly was accomplished by demonstrating that in response to forc- 
ing DI15 without an engine failure, the discrete was detected the same as for 
a valid S-IB inboard engine failure. A program block trace was utilized to 
verify that this discrete is checked once per BML, until detection, during the 

time interval from Tl+T_,_^ seconds until TB3. 

SI FO 

7.4.16 Dll 6: Prepare for Guidance Reference Release 

DI16 is used only by the ground routines and there is no requirement for the 
flight program to monitor this discrete. Verification that Dll 6 is never moni- 
tored was accomplished by checking that no program reaction results from 
DI16 being activated. 

7.4.17 Dll 7: Spare 
Verification was the same as fo:* DI3. 

7.4.18 Dll 8: Spar e 
Verification was the same as for DI3. 

7.4. 19 Dll 9: Spare 

Verification was the same as for DI3. 

7.4.20 DI20: Spacecraft Initiation of S-IVB Engine Cutoff 

There is currently no requirement to check DI20. Verification of program re- 
sponse \o DI20 was the same as for DI3, 

7.4.21 DI21 : Spare 
Verification was the same as for DI3. 
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\ 7.4.22 D122: Sparc 

Verification was the same as for DI3. 

7.4.23 DI23: S-ID Outboard Engines Cutoff ’TV' 

DI23 is the backup signal for starting TBS. The correct program response to 
this discrete was veritied by forcing the discrete and using a program trace 
to demonstrate that DI23 will start TBS properly. 

7.4.24 DI24: Liftoff 

This discrete indicates that liftoff has occurred. The proper program response 
to DI24 was verified by demonstrating that TBl is initiated by recognition of 
this discrete. A program trace was used to verify that DI24 is detected within 
the specified time. 

7.4.25 DIS1-DIS8: Spares 
Verification was the same as for DI3. 

7. 5 INTERRUPTS 

The LVDC hae a feature which permits interruption of tht* normal program 
to free the computer for priority tasks. When such a priority task arises, 
an interrupt is generated. This transfers control to a special routine upon 
the completion of the instruction then being executed. 

Of the twelve interrupts, nine are external and three are provided for 
functions internal to the LVDC. The correct program response to each 
interrupt was verified as discussed in the following paragraphs. 


As an assurance that an interrupt is honored only in the proper time frames, 
each interrupt was forced during the following intervals: 

• Prior to the specified enable time 

• After the interrupt has been honored 

• After the interrupt has been disabled 

7. 5. 1 INTI: Command LVDA/RCA^l 1 OA Interrupt 

This signal is u^^cd in the prcfliglU routines and there is no requirement to pro- 
cess it by the flight program. Verification that this interrupt is not processed 
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was accomplished by activating the interrupt during several parts of the mission 
and checking that no program reaction results. 

7.5.2 INT2: S-.ir5 Low Level Se nsors Dr y 

This interrupt indicates that the propellant level in either the S-IB fuel tanks 
or LOX tanks has dropped below a given level. The initiation of TB2 in re- 
sponse to the activation of INT2 verified correct flight program response to 
this interrupt. 

7.5.3 INT3: RCA-llOA Interrupt 
See discussion for INTI. 

7.5.4 INT4: S-IVB Engine Out 

INT4 indicates that the S-IVB engine is out and is one of the conditions which 
initiates TB4. The correct program response to this interrupt was verified 
by forcing the interrupt and utilizing a program trace to demonstrate tiiat the 
presence of INT4 is noted as one of the conditions for starting TI^4. INT4 
and each other condition for starting TB4 were forced to verify all logic paths. 

7. 5. 5 INT5: S-IP> Outboard Engines Cutoff 

This interrupt indicates that the propellant in the S-IB fuel tanks has depicted 
and is the primary signal for initiating TB3. The correct prograi^n response 
to INT5 was verified by demonstrating that TB3 is initiated by detection of 
this interrupt. 

7. 5. 6 INT6: S-IB Low Level Sensors Dry *'B’’ 

Verification was the same as for INT2. 

7. 5. 7 INT7: Guidance Reference R elease (GRR) 

This interrupt is initiated by the launch sequencer and indicates that the sta- 
bilized platform has been released. Correct processing of this interrupt was 
verified during the preflight prepare to launch (PTL) mode by demonstrating 
that TBO is started by detection of this interrup>t. 

7. 5. 8 INT8A and INT81^: Command Decoder Intcrr\ipt r "A” ind *^B’* 

This interrupt indicates to the LVDC that a DCS comnuind has been rc'ceived by 
the command dcc(u!cr. Th.e correct rcsp<jnse with rc'sp(!ct to IN’TH was verifi<‘d 
by demonstrating that the program sets vip to process a DCS coiTimand when 
this interrupt is activated. 
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7# 5« 9 INT9: TLC-vSimultaneous Memory Error 

This interrupt indicates either a memory parity error or a memory drive cur- 
rent check failure* Correct program response to INl'9 v/as verified by fc;rcing 
the interrupt at various mission times to test for execution of the specified 
recovery modes* In each case, correct telemetry coding was verified, proper 
DOR h ICR reset checked and EMR accumulation ensured through analysis of 
6D/LVDC program execution traces of the TLC module. 

7.5.10 INTIO: Spare 

INTIO is a spare and there is no requirement for the flight program to process 
this interrupt. Verification that the program does not react to this interrupt 
was accomplished by forcing INTIO and checking that no program response 
occurs. 


7.5.11 INTll and INT12: Internal Function of the LVDC 


These two interrupts arc provided to the LVDC for functions internal to the 
computer. INT12 is referred to as the Timer 1 interrupt and is used to con- 
trol the execution of priority modules which require operation at an exact 
time or at a precisely cyclic rate. INTll is referred to as the Timer 2 
Interrupt and Is used to control the execution of priority modules of a lower 
order than those under Timer 1 but which also require operation at a specific 
time or rate as precisely as possible. 

The correct prograrri response to INTll and INTI 2 was verified indirectly In 
verification of the functions ^hich they control; namely, for INT12, nnnor 
loop, switch selector processing, and liftoff search; and, for INTll, Phase 
I and II time update, events processor, time tilt guidance, and Phase II 
control. 
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SECTION 3 N75 33121 

LAUNCH VEHICLE ATTITUDE CONTROL 
8. 1 INTRODUCTION 

The flight program maintains correct vehicle attitude control via the minor 
loop and minor loop support modules by generating vehicle attitude error 
signals. This section describes the verification of the minor loop and minor 
loop support modules of the flight program. Logic was checked during boost 
and orbit (unusual timing situations necessitate the additional orbit checks) 
and the constants used by these modules checked at every point during the 
flight. Since the same logic instructions are used throughout the flight with 
only the constants changing, verification of the logic at two points and the 
constants at all points verified the logic throughout the flight. 

8.2 MINOR LOOP 

The minor loop properly es platform gimbal angle data, evaluates this 

lata, and con^putes and attitude error commands. Verification was 

accon.plished by exercising the various logic paths and checking th(‘ lindts, 
constants, and execution timing. 

8.2.1 Gimlial An gle Da ta 

The fine girr.bal angle resolver initially selected in each avia. Backup re- 
solvers arc properly selected m each axis when fine gimbal failures are 
forced as described in the lollowing paragraphs. The gimbal reading bit 
pattern was correct in all cases. 

Verification of rer^^lvcr reading initialization for both fine and backup con- 
figuration is discussed in paragraph 3.2.2, 

8.2.2 Gimbal Data Processing 

The gimbal resolver readings correctly undergo several validity tests before 
they are used to compute vehicle attitude and attitude error commands. The 
following paragraphs describe the verification of the logic used to detect 
erroneous gimbal angle readings. 

8. 2. 2,1 Disagreement Bit Processing 

The counters arc correctly determined to be in disagrt'ement whenever the 
A and B readings disagree by more than -13 or loss than -4 bits. Verification 
runs were made with the following combinations of differences between the 
A and B counter rcaciings and the state of the disagreement bit (DGB): 

(a) Positive and negative differences just within tolerance and the 
DGl^ on, 
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(b) Zero difference with the DGH on, 

(c) Positive and negative differences just out of tolcrarue with 
the DGB off, and 

(d) Positive and negative differences just out of tolerance with 
the DGB on. 

The flight program properly determines the valid and invalid disagreement 
bit and keeps account of the disagreement bit circuitry failures. 

After a valid disagreement had been detected, the counters were perturbed 
by simulating in and out of tolerance counter readings when the flight pro- 
gram addressed the counters for incrementation at a known frequency. The 
following combinations were used to verify the programme capability of de- 
tecting and compensating for counter malfunctions. 

(a) A and B counters within tolerance. 

(b) A and B counters out of tolerance. 

(c) A counter within and B counter out of tolerance. 

(d) B counter within and A counter out of tolerance. 

The proper counter reading is selected for rea .'^v'nablcne s s testing in eacli 
case and the program keeps account of the number of counter failures. T\V(^ 
failures of citiicr counter in the s[)ecified time results ii^ the disagreement 
bit processing being permanently bypassed and the other counter selected. 
Failure of both counters twice in the specified tirne results in the guidarue 
reference failure discretes being set. 

When a valid disagreement is detected iincl both counters are within tolerarut , 
the flight progra n selects the A counter reading for rea sc nableiu‘ s s testing. 

If the A counter reading is found reasonable, a B multiplexer failure is 
assumed and the B mult iplext' r failure* <.ount<r is inc re me ntt'd , If the A 
counter reading is found unrt*a sonable, an A multiplexer failure is assumed 
and the A multiph;xor failure counti‘r is incremented. If the* A multipB xer 
is in error twice or the B multiplexer is in t'rror five tinges in the* specifiiui 
time, disagreetnent bit processing is permanently bypassed and the (ounter 
corresponding to the otiu*r multiplexer is permanently sc*lected fern re«ison- 
ablcness testing. 

All program logic was implementiul properly and all mode code' bits we*re* set 
cor rectly. 
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8. 2. 2,2 Reasonableness Tests 

Both reasonableness tests, unreasonable zero and unreasonable chan^i* are 
performed properly on tlic selected gimbal an^lo readings* Verification was 
accomplished as discussed in the following paragraphs. 

Readings wore simulated that forced the attitude error signals to values less 
than, equal to, and grentor than {in both positive and negative directions) thiC 
zero test constant in each axis. The program pronorly selects the reason- 
able readings to update the vehicle attitude angle and rejects the unreason- 
able readings*. 

Girnbal angle readings were forced on both sides of the resolver reasonable- 
ness test constant. The resolver overflow test was also exercised in the 
same manner. The program properly determines the reasonable and un- 
reasonable readings. 

Reasonableness test verification was accoT'iqjlished for both fine and backup 
resolvcTs in each axis. The counters tiiat keep track of the f‘rror rates 
are incremented and reset properly. 

8. 2. 2. 3 Minor Loop Lrror Telemetry 

The n'linor loop error word is telemetered in the correct fornuit and at tin- 
appropriate time in all cases. Verification was accotnplisluul by obtaining 
a printout of the minor loop telemetry word in each of the minor loop v(-ri- 
fication cases. 

8.2.3 Attitude Error Cnnimanris 

The equations used to compute the minor loop attitude commands are imple- 
mented properly. Verification was ac c ompl i sh.eri by using independent cal- 
culations for each axis. Extreme desired veliicJe attitudes werr forced, 
but the attitude command magnitude and rat(‘ wi*re litnited prcjperly. 

The error n^(jnitor register indication of circuitrv failure was forced tr> 
verify the selection of the proper ladder channel. The channels wt*re selec- 
ted properly and the counter that keeps track of circuitry failur<*s was incre- 
mented and reset pro[)crly. 

8.3 MINOR LOOP SUPPORT 

The n^inor loop support functions properly con oute attitude change increments 
and the coeff ici('nts for the g i^*’^hal - to-bod y transformation to hv *ised in the 
minor loop. Verificatiem of the iiiinor loop sup!>ort functions is described 
below. 
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8.3.1 Attitacio Increments 

The desired attitude conunands arc* computed {properly (*ach minor loo[) by 
adding the fixed incrcnu-nts to tiie previous attitude command values, 
putation of the attitude incre uents for use by the minor loop module was 
checked fc3r each platform axis with independent equation solutions. Propi*r 
attitude change magnitude limiting was verified through analysis of tiie minor 
loop and minor loop support telemetry wiien la^-ge desirc’d attitude commands 
were given. Correct bypassing of thc‘ steering misalignment correct’' :: 
(SMC) terms during iterative guidance mode (ICM) of flight v.as verified by 
performance cases containing perturbations which cauac^d the attitude com- 
mand increments to exceed the magnitude limits. 

8.3.2 Gimhal-to- Hody Transformation 

The calculations required to obtain the predicterj roll and yaw average atti- 
tude angles for compensation of the changing relationship between the vehicle 
body and the inertial platforn^ were executed properly. Verification was 
accomplisiied through independc*nt solutions of the equations. 

The special logic required for average roll attitiuic angle determination was 
executed properly. Verification was accomplished by forcing tlu* differonte 
between predicted and actual angles to values that lie on either side of tiie 
crossover magnitude (180°). Coefficients needed by the minor loop module 
for transformation of the attitude errors froni the gimbal coorrlinate systi*m 
to the vehicle co(»rdinato systen'i wc^re calculated inde[)end ntly and compared 
to those values computed by the flight program, 

8.3.3 L oss of APS Attitude* Control Test 

The X and Z attitude control tests were enabh‘d properly and correctly de- 
tected attitude errors whicti exceedc'd tlie specified test constants. 'Hie lad- 
der magnitufio limit was set to twelve degrees when an X or Z attitude con- 
trol failure was determined providt*d the nor’ninal timeline rlid ru)t specify 
a larger magnitude limit for an axis. Correct priority between th<* Lulder 
magnitude limit following an attitude ct)ntrol test failure, DCS Ladder 
Magnitude Limit ccjinnumd, anrl nominal tinudine changt*s was verified, 

Th<‘ APS attitucle control test is correctly dis«ibled after detection of an 
attitude control failur*' or after iss*;anc<‘ of the DC*S Ladder .Magnitude 
Lindt command . 
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SECTION 9 N75 33122 

SWITCH SELECTOR PROCESSING 

9. 1 INTRODUCTION 

Switch selector commands are correctly issued under program control to 
provide sequencing signals to the launch vehicle hardware. This section 
discusses the verification accomplished to assure proper program execu- 
tion of the switch selector commands. 

9.2 COMMAND EXECUTION OPERATIONS 

All the separate program operations required to properly issue one switch 
selector command are executed properly. Verification of the correct exe- 
cution of each operation was accomplished as outlined below. 

9.2.1 Sequence of Operation 

The sequence of operation refers to the order of execution and timing require- 
ments of each step necessary to activate a switch selector command. Cor- 
rect execution of each step and maintenance of the minimum timing require- 
ments between steps wore verified through analysis of a series of 6D/LVDC 
intermediate timing cases. Nominal and perturbed switch selector feedback 
conditions wore simulated to verify correct processing of all realistic 
sequencing and timing combinations. 

9.2.1. 1 Hung Stage Test 

The hung stage test correctly checks the address feedback to assure all inputs 
are zero. The proper execution of this test was verified by forcing the ad- 
dress feedback to be non-zero and checking the program’s response. All 
switch selectors from GRR to T4 + 100 were tested to verify that the hung 
stage test was made prior to issuing commands which require a forced 
reset for hung stage conditions. Sequencing from GRR to T4 + 100 includes all 
of the types of switch selectors which require the hung stage test. 

9.2. 1.2 Stage and Address 

After the hung stage test, the flight program correctly issues the stage and 
address. This operation was verified by comparing the issued stage and ad- 
dress against the expected stage and address and also by checking that the 
correct telemetry was issued. 



9-1 


9.2. 1.3 


Address Verification 


After issuance of the stage and address, the switch selector feedback is pro- 
perly checked. This operation was verified by forcing feedback errors 
and checking that the program executed the proper corrective action including 
mode code bit setting, internal control register bit resetting, and telemetry 
when required. One bit feedback error, all bit feedback error, and all zero 
feedback were forced to verify all possible logic paths involved with this 
operation. 

9.2. 1.4 Read Command 

The read command correctly activates the logic on the switch selector to pro- 
duce the commanded output. This operation was verified by comparing the 
stage, address and associated real-time clock reading telemetry after read 
command issuance with tl:e output from the simulated oD switch selector 
register. 

9.2. 1.5 Reset Read 

The reset of the read command is correctly issued no less than 25 ms after 
the read command is issued. This operation was verified by the series of 
hD/LVDC switch selector cases by checking that the read command for each 

switch selector is not reset until the specified interval (Z5 ms) had elapsed. 
9.2.2 Termination of a Command wSequence 

A command which is in progress can be properly terminated by issuance of 
a forced reset. Verification was accompUshed by forcing the conditions 
which require a forced reset (by a TLC> a hung sta^e failure or by feedijack 
errors) and observing that the proper termination was completed. 

9. 3 TIMING 

The timing requirements for all switch selector commands arc properly 
satisfied. Switch selector timing was verified by comparing the times of 
all switch selector read commands, for the nominal sequence and all alter- 
nate sequences, with the issuance times specified by the Flight Sequencing 
table. All switch se.*.ector commands were issued within the specified 
tolerance. 

9.4 PRIORITIES 

When requirements for simultaneous issuance of switch selector commands 
occur, the commands arc issued correctly with the following priority: 

A. Class I alternate sequence 

1. S-IVB cutoff switch selector 
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B. Class II alternate sequence 

None defined for this mission ^ 

C. Nominal flij^ht sequence 

D. Class III alternate sequence 

1. Generalized switch selector 

2. Coolant valve 

E. Class IV alternate sequence 

L Telemetry station acquisition sequence 

2. LOX depletion dump start sequence 

3. LOX depletion dump stop and LH2 
depletion dump start sequence 

4. Start safine sequence 

The hierarchy of these switch selector commands was verified by forcing 
the requirements for simultaneous switch selectors, where the possibility 
exists for interference, and then checkin<j that the corr ct priority was 
followed . 

There were >o simulations made for each interaction. The first simulation 
was designed such that the sequence of operations for the lower priority 
switch selector would be in progress when the requirements for issuing the 
higher priority switch selector were introduced. In each of these tests, tlu* 
lower priority sequence was correctly interrupted and replaced by that of 
the higher priority sequence. Depending upon specifications, the sequence 
of operations for the lower priority switch selector would he re-entererl aiul 
the command correctly issued or the sequence of operations would be cor- 
rectly terminated. The second simulation was the sequence for the higher 
priority switch selector in progress when the conditions for issuing the 
lower priority switch selector were introduced. In these; tests, the; hiclier 
priority sequence would not i)e interrupted and the command would In; pro- 
perly issued. The lower priority sequence was then, depending upon speci- 
fications, either re-initiated and the command correctly issued or correctly 
terminated. 
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N75 33123 

SECTION 10 

DIGITAL COMMAND SYSTEM 

10. 1 INTRODUCTION 

The Digital Command System (DCS) correctly provides a limited real-time 
means of controlling specific flight program functions. Correct processing 
of DCS commands by the flight program was verified as outlined in the fol- 
lowing paragraphs. 

10.2 DCS WORD FORMAT 

The flight program has the capability to correctly read and process the infor- 
mation stored in the command decoder register upon receipt of the AND cd 
interrupt bits. Also, correct interpretation of the AND ed orbital rnodc/data 
bits is performed properly. Verification was accomplished each time a DCS 
command was issued by checking that the command was recognized correctly 
by the flight program. 

10.3 DCS COMMAND VERIFICATION 

Upon detection of the command decoder interrupt (INT8), the flight program 
correctly reads the contents of the command decoder register and makes 
several tests on the DCS command before it is accepted for use. Correct 
flight program implementation of the checks required to establish the vali- 
dity of the data received from the command decoder was tested using the 
methods described below. A generalized switch selector mode command 
was issued after T4 + 0 to ensure that the command decoder discrete output 
(DOl) is set and the DCS error counter is zeroed. 

10.3.1 DCS Mode Command Verification 

The flight program has the capability to correctly detect DCS mode command 
format errors. Verification was accomplished by pcrforniing the follov/ing 
DCS command verification tests. Running the perturbation in the order listed 
verified that the flight program tests were performed in the correct sequence, 

1. True complement test: A sequence of mode commands requiring 
no data words was issued with combinations of correctly and 
incorrectly coded complement l^its. Proper rejection, accep- 
tance and error code 10 telemetry was executed. 
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2. Sequence hit test: A sequence of mode commands not requiring 
data words was issued with valid and invalid sequence hits. Cor- 
rect rejection of invalid mode formats and error code 24 tele- 
metry was performed, 

3. Terminate command test: Terminate commands were issui^d 
following 1) a memory dump request, 2) a compressed data dump, 
3) issuance of a mode command requirine data, and 4) durinv each 
DCS time frame. Proper bypassing of the specified tests was 
achieved, 

4. Mode expected test: A DCS sequence containing modes which do 
and do not require data words was sent to the flicht program. 
Correct rejection of invalid configurations and correct error 
code 20 telemetry was accomplished. 

5. Memory dump or compressed data dump in progress test: A 
memory dump command and a compressed data dump command 
were issued while another memory dump and compressed data 
duinp was in progress. Error code i>4 telemetry was correctly 
issued. 

6. Mission acceptance test: All possible DCS mode commands 
(00 to 77)^ were issued in each DCS time frame to ensure that 
modes not defined for the mission were correctly rejected and 
error code 14 was telemetered, 

7. Time acceptance tests: All mission defined mode commands and 
associated data words were sent to the flight progran'i durinc eacl'i 
DCS time frame. Correct acceptance and rejection a fimction 
of the tiiT e frame was performed properly and error code 74 
was correctly issued. 

8. Pending generalized switch selector test: A generalized switcli 
selector command was issued while a previously issued gener- 
alized switch selector command was waiting to hv. processed. 

The first command was issued at a time to cause tlie uener "izorl 
switch selector to e delayed by a nominal tabled switcli selector. 
The second command was reiected and wror code 34 issued. 

The simulator monitored the discrete output register to verify correct setting 
by the DCS routines. If DOl was not set within 400 nnllisec onds after tiie DCS 
interrupt (INT^), rejection of tl.e comnmnd was assumed. Correc t teletnetrv 
of DCS mode status indicators anr] error code words was pc^rformed properly 
on all siniulation runs. 

10,3,2 DCS ]3ata Command Verification 

When a DCS data command is recei\(‘d, the flight program correctly performs 
several tests before the command is accepted. Verification of these tests was 
performed in the following sequence to ensure that the llight program checks 
arc in the specified order. 
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1. Data le^al test: A ucnerali/.ed switcli selector mode and ilu < e 
data commands (only two required) were issued to % erify this 
requirement. The last data command was correctly rejected 
and error code 04 was issued, 

2. True-complement test: A corrtrctly coded miodc command re- 
quiring data words was issued with various combinations o( data 
commands with valid and invalid complement bit confii'urations 
and correct sequence hit format. The invalid data was correctly 
rejected and error code 44 was issued, 

3. Sequence bit test: A valid mode word followed by data words with 
correct complement bit patterns but \alid and invalid sequence 
bit 'alues was sent to the fli-dit prouram. The invalid words 
were correctly rejected and error code vO was issued. 

Telemetry requirements for DCS error messa<:jes and the data status indicator 
were verified in all simulation runs. 

10.3,3 DCS Data Validation 

The data for some mode commands required further testing after beinu recci'.ed 
and formatted. 

• Illegal memory dump test: Memory dump con:imands requesting 

data from non-existant modules and where the start module, 
sector and address w*as {greater than the end module, sector, 
and address were commanded. The c ommands were properly 
rejected and error code SO issued. Further \er ificat ion of this 
test is described in paragraph 10,4.4. 

• Valid time test: The program properly rejected a Na\ication Uprlatc 

command and an S-IVl^/lU De-orbit command with inqdeinentation 
time of less than 10 seconds in the future. A TB*^ start time of 
less than w^as properly rejected. Error code S4 was cor- 

rectly issued following these rejections. 

10. 3,4 DCS Error Message 

Each time the program rejects a DCS command, an error message is c orrectly 
telemetered. Error telemetry formal was verified in the; simulations described 
above. Issuance of DCS error messages exceeding seven consecutive failures 
verified the implementation of the error counter and automatic terminate ( om- 
mand initiation. Error Code 70 could not be verified since no execute alternate 
sequence command is defined for this mission, 

10, 4 DCS COMMANDS 

The flight program correctly accepts and })rocesses all the I^CS commands de- 
fined for this rnirsion. The following paragraphs discuss the \vsis usee] to 
verify the operation of these DCS commands. 
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10.4.1 Time Base Update 

The time base update command correctly increments or decrements tiiuc 
in the time base by an amount specified by an accon;oa n vin •; DCS data comi:a'nr]. 
l';Oth positive and negative \m1ucs of maxinium, minimum, ,*::d least s i un if i c.' n i 
magnitudes were tester) for accuracy of tiriic t asc tin.e cbanfj.e. A p'ositivi* tin^e 
base update of maximum magnitude was issued immediately after a station ac- 
quisition to ensure that the calibration switch selectors were issued at maxi- 
mum rate. A negative maximxim update issued after T4 + 0 was used to verify 
that switch selectors cannot be reissued. Time base updates of maximum 
positive magnitude were given prior to each orbital guidance maneuver to 
verify that the times for the maneuvers are not changed. It was verified 
that a time base update is not accepted in TB5 and that the biased time base 
time is reset at TB5+0. A time base update was issued after the last tabled 
switch selector. in TB4 to verify implementation. 

Multiple time base updates (both positive and negative) were issued to cheeb. 
correct bias accumulation. Also, a terminate command was issued to ensure 
that it had no effect upon update implementation. Bit 9 of Mode Code 27 wa»; 
used to indicate correct time base update command implementation. 

10.4.2 Navigation Updat e 

The navigation update command correctly replaces the orbital navigatio i state 
vector with one supplied from the ground. The accuracy of the navigation 
state vector component replacement was verified with a navigation update wita 
an implementation time (NUPTIM) greater than 10 seconds in the future. A 
navigation update with NUPTIM less than 10 seconds in the future was issued 
to verify rejection, automatic program initiated terminate, and error code 54 
telemetry. Multiple navigation updates were sent to the flight program with 
NUPTIMl more than 10 seconds in the future and NUPTIM2 less than 10 sec- 
onds in the future to ensure that the second update is rejected with no effc*ct 
on the first. Multiple updates with Nt JPTIM2> N UPTIM 1 > 10 seconds in the 
future were issued to verify that the last navigation update accepted replaces 
previous updates. Mode Code 27, bit 8, was correct on each update simula- 
tion run. A terminate command did not affect the navigation update. A mem- 
ory dump verified proper storage of the updated parameters. 

10.4.3 Generalized Switch Selector 

A sequence of generalized switch selectors was issued in all DCS time frames 
to check for correct nominal operation. Error code 34 was generated by re- 
questing generalized switch selectors at maximum rate during a flight peric'd 
with high speed density tabled switch selectors. The flight program will not 
issue a generalized switch selector command if there is less than 500 i^is 
until the next preprogrammed switch sclectv)r. Terminate commands issued 
after the second data word were used to verify the no effect requir«‘menf ' 
switch selector issuance. Attempts to obtain complen^ent switch v* j . ^ r s 
were made to ensure that all commands are treated as true i^'h'iress switch 
selectors and bit 8 of the switch selector address is ignore . by the pro^ rarn. 
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The generalized switch selector is classified as a Class III alti'inatc- sequence 
and its priority was tested, where the possibility existed for interference, 
with other types of switch selectors. Further discussion of switch selector 
priority verification is contained in Section 9.4. 

10.4.4 Memory Dump 

This DCS command correctly causes the flight prograni to telemeter the memorv 
locations specified by the accompanying data words. A memory dump conin^.and 
was issued for telemetry of a memory portion greater than 16 words (a block). 

It was verified that the first word of the block telemetered does identify the 
first memory word telemetered. A memory dump command including a portion 
of data requested from a non-existent module was issued to verify rejectitm of 
the command. The start module, sector and address must be less than or 
equal to the end module, sector and address requested. Correct implcn'icnta- 
tion of memory dump commands requesting from one to fifteen memory loca- 
tions was verified, A memory dump command was issued requesting data 
from an odd-numbered module to ensure that the telemetered data was fron^ 
an even-numbered module. Terminate commands were issued during all por- 
tions of memory dump to verify that the terminate will stop the dump, 

10.4.5 Terminate 

In addition to the tests herein outlined, a torniinate was tested with respc*ct to 
all mode commands requiring data to ensure correct DCS routine resetting 
before all required data words had been accepted. 

10.4.6 Execute Ccnerallzc-d Kl aneuvc r 

The implementation of both types of generalized orbital maneuvers, inertial 
hold and track local reference, was verified b’ issuing the appropriate DCCS 
mode command and the 20 DCS data commands. 

Commands with T _ equal to zero and some time in the past were implemrn- 
ted within one con\putation cycle (after all data was received and fornm tted). 
Commands with equal to a future time were implemented at tiie Lurrect 

time. 

A check was made to verify the correct u&agc of the three reference anaU s, 

^ref* ^ref' flight program and the setting of the correct 

mode code bits. A memory dump was comn\anded to verify correct storage* 
of the execute generalized numeuvor parameters. 

The ger>cralized nianeuver command remains in effect until furtiier DCbS ac tnui 
commands another tnxecuted generalized maneuver or return to nominal tiir.e- 
lino. Correct setting of MC27 bits in conjunction with this DCS command 
was established. 

Correct interaction of the generalized maneuver with D19 was verified in a t(*st 
series which included botn inertial hold and track local reference nnaneuvers. 
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With the spacecraft iti control of Saturn (DI9 set), an Execute Inertial Hold 
Maneuver DCS command was accepted followed by a l^vCturn to Nominal 
Timeline DCS command. Upon the return of control to the instrument unit 
(DI9 reset) the flight program executed the pi eprograinmed 1 rack Local 
Reference maneuver. Subsequently, control was switched to the spacecraft 
followed by an acceptable Execute Inertial Hold Maneuver, Upon th(' return 
of control to the instrurnetit unit the flight program execvited tJie commanded 
Inertial Hold maneuver. An execute generalized maneuver command was 
issued before a pending execute getieralized maneuver and a return to nomiiial 
tiiTieline DCS command was implemented to verify the replacenient of the 
pending command by the current command. A terminate command was issued 
after the 20th valid data command was received to verify that it does not pre- 
vent the execute generalized maneuver commaiid implementation. 

A generalized maneuver command with a scheduled to occur after the 

start of TBS was issued and a memory dump commanded to verify that the 
storage locations of the generalized maneuvers are zeroed at T1^5 + 0. 

10.4.7 Return to Nominal Tirnclino 

This DCS mode command provides the caj^ahility to return to the nominal time- 
line after other DCvS action has been initiated to override the preprogrammed 
orbital attitude timeline. The lime to return to nominal time (Tj^^yi ) is sent 
in five DCS data commands. A return to nominal limeline comniand was 
issued with in the future to verify the cc^rrect storage of the 

zeroing of all bits in the location in which GOMTYH (generalized orbital ma- 
neuver type) is stored, except a 1 in bit 2, and the zeroing of nu^mory loca- 
tions containing the reference angles for a pending execute generalized 
maneuver. A conmiand was issued with "1 cqiial to zero and s(jme tin^e 

in the past to establish that the command was implemented within t>ne com- 
putation cycle (after the data is received). 

A return to noiriinal timeline con^mand was issued before a penrling return to 
nominal timeline and execute generalized maneuver comnuand was imph'men- 
ted to verify the replacing of the pending command by the current command. 
After the fifth valid data comnuand wais received, a ternUnalc* command was 
issued to demonstrate that it docs not prevetit the return to nominal time- 
line command. The mcn’iory locations containing the data for lhf‘ return to 
nominal timeline con'imand are zeroed at TB^.O, 

10.4.8 ECS Water Control Valve I.ogic inhibit 

Correct operation of this mode command was vcrific*d in the E(hS water valve 
logic test defined in Sections 7,4,10 and 7.4.11, 

10.4.9 Exi-cute Maneuver 

This DCS command will provide the capability to initiate .i spe cialized orbital 
maneuver. Tins command is presently not deTined; tluTefore, no verification 
was done on this command. 
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10.4, 10 Altc r n ate Scgu en c 

rher? are presently no DCS alternate sequences defined. No verification 
perforn^ed on this command. 

10.4. 11 Tarf^etinfi Load 

This DCS command is used in proflight mode only; therefore, this command 
will not be verified as part of flight mode verification. It was verified that 
this command was not enabled during flight. Additional verification of this 
command is described in paragraph 3. Z. 

10.4. IZ Ladder Magnitude Limit 

A Ladder Magnitude Limit command was issued with the least significant 
value in the data word to verify the accuracy of the implementation of the 
command. A con^.n'iand with the maxin'iiirn possible value was issued to 
verify proper limiting of the con^mand. 

This command was issued followed by aii attempt by the nominal tirncliiu* 
to change the ladder n^agnitude liniits to values less than and greater than 
those specified by the command. The progran^ used the correct limits. 

The loss of APS attitude control test was failed after giving the Ladder 
Magnitude Limit cornniand to verify that tlu* limits are set to LML. This 
was followed by another command with limits smaller than lA* L to verify 
that the limits remain at LML. This portion w^.r verified in conjunction 
with Section 8. 3. 3. 

10.4.13 S-IVH/IU De-orbit 

The DCS S-IVn/IU De-orbit commanc! correctly begins 'IT; 5, [perforins the* 
required initializations, and issues the specified <ilternate switch selector 
sequences. 

The data commands are formatted correctly by the fliglit program. 'Ilie m.ix- 
imum and minimum duration times s[>ecified by the flata con-imarKls were* veri- 
fied. The start time of TH5 as s[)OCified in the DCS command is prfU)erly 
tested to ensure that the start time is greater than least 10 

seconds in the future. The pr<^gram properly rejfu ts t\ie command, issu(‘s 
error code 54 and [icrforms an automatic program initiated it*rminate if 
either of th.cse tests is failed. 
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S-IVR/IIJ De-orhil commands were issuerl with 'rhOD-O, l')KhVK 0, 
and THnn~0. When TLOO is zero, the LOX and liyflrojen flumps are 
bypassed anri the safinu sequence is S( heflulerl to start at seconrls. 

Wlien DKLvVIx is zero, the \elocity test is bypasst^d and the hOX and 
hydrouen dumps w^ere performed tor the duration defined by I LDD arzi 
Tlinn, When DKLVR is non-zero, the flumps are lerminatefi <irvi Lhe 
safin^ sequence startefl when the total measurcfl \elocity becomes equal 
to or ereater than DKLVR. \\ lien ddlDD is zero, the LOX dump is termi- 
nated by scheduling the safing sequence to start immediately lollowine tlie 
LOX dump. Commands with \arious \alues of TLDD, THDD, and DKL\d\ 
were issued to cause the velocity test to be satisfieri during ever> possible 
segment of the LOX and hydrogen dumps. In e\ery case, the \elocity t<‘st 
is terminatcfl when the safing sequence is scheduled. 

The four quantities from the data commands are properly scalerl and stored 
by the flight program. A de-orbit command, accepted before T Ba is startt‘fi 
in response to a previous de-orbit command, correctly replaces the prt‘- 
vious command. The de -orbit con'imand is not accerterl in TB)a. 

Mode Code 2 7, bit 7, is set and reset properly, 

10,4,14 Compressed Data D\imp 

This DCS conunand prO' ides the capability for coinmaiuling a dump of the ( om- 
pressed data tai)les. 

Upon ac:cc‘ptance of this command, the llight program will dump the cornpresst : 
data tables three times in their entirety. The rompressev! flat a flun’ip will -v 
stopped only by receipt of a terminate c omn'iand. Other irorlc-s comrnanfied 
during a dump are ac cepted except a memory diu'i'ip or another c cunpre* s 
data dunip which are rejected and error code » 4 will ' e issuevi. 

Verification of the flata container! in the comprvssefi rlata tables is flescrilwrl 
in Section 11, ^.2. 

10.4.1^ Remo^e Inhibit on the F!\trac tion Mane ir.er 

The Remo'e Inhibit on the* ILvtractiun Nt.ineU'.er command was issued prior 
to the noH'iinal start time of Maneir er v. Maneu ers » , 7, anrl S were 
started vit the nominal times. The c oi^imaiul was issued alter the nominal 
start times for Manou\er ♦ , 7, anrl s. In each caisc M.tm-ir er e was started 
immediately anfl Maneu\ers 7 and ' were* dc-layed by the same- amount ol lime 
that Maneu\er » was rUTayefl, I^)it ot inofle ce;fU* 2 7 set profa rlv in 

e'cry case. The r iminal start time deltas ar<- nutintained unless ground 
command mammers or spacc*c ralt eontrol art* inter s ]>e r se*rl with these 
maneu\ er s. 
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Multiple commands were issued in Time 4, The first command 

removed the inhibit on the extraction maneuver, Tlu* subsequent 
commands wtme propi*rly accepted, l^ut had no furtlu^r effect. The 
command was issued in Time Masc S, ’out it was properly rejected 
and error code i4 was issued. 
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SECTION 11 

REAL TIME TELEMETRY AND DATA COMPRESSION 


11. 1 INTRODUCTION 

The flight program correctly provides telemetry and data compression. 
Verification of this activity is described in the following paragraphs. 

11. 2 TELEMETRY SYSTEM INTERFACE 

The adequacy of flight program telemetry control and timing was proven 
by the analysis of Sim Lab runs of past programs through the use of 
telemetry. 

11.3 IDENTIFICATION TAGS 

The telemetry data is correctly issued using specific tags called PIO 
(process input /output) tags. The flight program controls only portions 
of the composite 40 bit telemetry word, the remaining parts being 
formed by the telemetry system hardw^are. Verification was accomplished 
by ensuring that a specific PIO tag and mode register setting identified 
the correct parameter and that the data was properly scaled for subsequent 
ground station reduction. 

The corresponde .ce between parameter, PIO tag and mode register 
setting was verified by checking the tabled data in the flight program against 
the tabled requirements in the EDD, A careful monitoring of changes to 
the EDD telemetry tables and symbolic tape compare of the implementation 
of these changes w^as used to ensure a fixed tag/quantity definition, 

11. 4 GENERAL REQUIREMENTS FOR LVDC AND LVDA TELEMETRY 

LVDC telemetry correctly adheres to the general requirements specified 
by the EDD. 

11.4.1 LVDC Telemetry 

The 6D/LVDC simulator monitors the length of time between execution of 
telemetry PIO instructions; therefore, all 6D/LVDC runs were checked for 
an insufficiency of time? (less than 4. 25 milliseconds) between these 
instructions. 
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11.4.1.1 LVDC Regularly Scheduled/When Computed Telemetry 

Correct implementation of the requirements for regularly scheduled/when 
computed telemetry was checked using the 6D/LVDC simulator. Naviga- 
tion, guidance, accelerometer, IGM, mode code and special parameter 
telemetry was verified through analysis of the outputs obtained from simu- 
lation p^'ccessing. For each flight phase, a comparison of the specified 
parameters and those monitored during the simulation was made to ensure 
that the flight program conforms to telemetry requirements. 

11.4.1.2 LVDC On-Occurrence Telemetry 

Telemetry indicating execution of a flight sequence event was verified 
through analysis of both nominal and perturbed simulations designed to 
cause the required condition. The format of data, identification codes 
and real-time clock readings were checked for discrete input and output 
registers, interrupt register, switch selector register, switch selector 
feedback register, and special event telemetry. 

11.5 DATA COMPRESSION 

Data compression specifications were verified using compressed data 
from nominal flight simulations and from a scries of perturbations designed 
to test data table overflows, data dump rates, and compression of data for 
on occurrence events. The results of the data compression are discussed 
below and also in Section 10. 4. 14. 

11.5.1 General Data Compression Requirements 

The telemetered compressed data tables were checked by monitoring the 
time, identification code and data formats. The table length and the maxi- 
mum compression period was verified by monitoring compressed data 
telemetry after table wraparound. The program correctly stores and 
telemeters all data types with the associated time, 

11.5.2 Data to be Compressed 

Time compressed (Group A), occurrence compressed (Group B) and 
amplitude compressed (Group C) data were verified using both nominal 
and perturbed simulations. Verification of each group is disucssed in 
the following paragraphs. 
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lU 5. 2. 1 Group A: Time Compressed Data 

Group A data was obtained from the nominal simulation. Fine and backup 
gimbal angle data and accelerometer data were checked to verify correct 
compression rates. 

11.5.2.2 Group B: Occurrence Compressed Data 

Group B data was forced in a series of simulations designed to verify 
correct storage of event data. Storage of discrete output register changes 
and both tabled and generalized switch selector data was ensured. TLC 
HOP constant compression was verified by checking the flight program 
logic flow, 

11. j. 2. 3 Group C: Amplitude Compressed Data 

Group C data was verified using both nominal and perturbed simulations 
to check compression of each function specified. Sample and storage 
rates for the functions of this group were checked by forcing system 
failures for MC24 and the Error Monitor Register and by setting and 
resetting various discrete input register bits. 

11*5.3 Telemetry of Compressed Data 

The compressed data tables are correctly telemetered three times when- 
ever the compressed data dump DCS command is received. The issuance 
of the compressed data telemetry was verified by checking the mode 
register setting, the telemetry PIO tags and the sequence in which the 
compressed data table locations were selected for telemetry. 
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SECTION 12 


PREFLIGHT TESTS 


Verification of the preflight routines is not a requirement in flight program 
verification. It was verified that the non-repeatable sim flight and repea- 
table sim flight modes do not interact with the flight mode. Section 1-3 
describes additional verification performed in the preflight prepare-to- 
launch routines. 
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SECTION 13 

ALGORITHMS N75 33125 


•3.1 INTRODUCTION 

This section describes the algorithms used in the flight program to approxi- 
mate elementary functions and mathematical procedures. The implementa- 
tion of these algorithms was checked by verifying that at least one, and in 
most cases, more than one function computed through the use of the algorithm 
is calcvilated properly. 

13.2 SINE-COSINE ALGORITHM 

The sine-cosine algorithm was verified by forcing input arguments in each 
quadrant and at 0®, 90®, 180®, and 270® and the results checked against 
tables. This algorithm is correctly used to obtain terms for the coordinate 
transformation matrices and verification was completed by checking the re- 
sults of these transformations. 


13. 3 ARCTANGENT ALGORITHM 

The arctangent algorithm was verified by inputting various values for 
the numerator and denominator arguments. This algorithm was tested 
in each quadrant and at 0^ , 90^ , 180® and 270® and the results checked 
against tables. This algorithm is used in the calculation of the range 
angle (0i), the desired vehicle pitch and yaw attitude {Xy and Xz) and 
the track local horizontal guidance commands upon return of control 
from S/C to lU, The verification of the calculation of these quantities 
completed the arctangent algorithm verification. 

13.4 NATURAL LOGARITHM ALGORITHM 

The natural logarithm algorithm was verified by inputting test arguments of 
1, less than 1, greater than 1 and the two end points. Verification of these 
logarithms and the correct calculation of the intermediate IGM terms :>f 
velocity-to-be-gained (Lj and L^) ensured the proper implementation of 
this algorithm. 
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13. SQUARE ROOT ALGORITHM 

This algorithm was verified by inputting positive, negati\e and zero arguments 
and checking the results for accuracy. The values for desired yaw attitude 
{Xz)f relative velocity (Vj-), and position (R ) were also checked to complete 
the verification. 


13.6 INVERSE SQUARE ROOT ALGORITHM 

The inverse square root algorithm is correctly implemented in the calculations 
for the inverse of the vehicle's radius from the center of the earth (1/R). Veri- 
fication was accomplished by hand chocking these calculations at initialization, 
during boost and during orbit. 

13.7 VECTOR DOT PRODUCT 

Several test cases were run using known vectors to verify the results from the 
vector dot product algorithm. Since the vector dot product is used in the rota- 
tion of gravity acceleration into the injection system and the gravity accelera- 
tions affect the guidance commands, correct IGM performance also indirectly 
verified the implementation of the vector dot product. 

13.8 VECTOR CROSS PRODUCT 

The transformation from one coordinate system to another is correctly accomp- 
lished by use of the vector cross product algorithm. The checks of these trans- 
formation matrices and the exercise of the algorithm using several known vec- 
tors assured the correct implementation of the cross product. 
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APPENDIX B 
PERFORMANCE CASES 

1. +5% thrust and mass flow rates in both stages 

2. -5% thrust and mass flow rates in both stages 

3. High stop PMR (HPMR) for duration of S-IVB 

4. Low stop PMR (LPMR) for duration of S-IVB 

5. All accelerometer hard failure (zero change), A channel 

6. X accelerometer hard failure (zero change), both channels 

7. Y accelerometer hard failure (zero change), both channels 

8. Z accelerometer hard failure (zero change), both channels 

9. Engine #1 out at Tl + 5 

10. Engine #6 out at liftoff 

11. Engine #4 out at Tl + 40 

12. Engines #1 and n/5 out at Tl + lOO 

13. Fine gimbal failure, fly on backups 

14. +2* B bias, +1* 9 bias 

P P 

15. -2* p bias, -1* 9 bias 

P P 

16. S-IB engine #1 actuator hardover inboard at 10 seconds 
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APPENDIX C 

PERFORMANCE CASE ANALYSIS 


CASE #1 - +5% THRUST AND MASS FLOW RATE FOR BOTH STAGES 

This case was accomplished by simulating a increase in the nominal 
thrust and mass flow rate of both the S-IB and S-IVB stage. As a result 
of the increased mass flow rate, the S-IB stage propellant low level 
sensor was activated at TBl+126.43 seconds, prior to the associated low 
level sense interrupt being hardware and software enabled at TBl+127.86 
seconds. Inboard engines cutoff occurred as scheduled at TB2 + 3.0 seconds, 
but fuel depletion occurred at TB2 + 3. 20 seconds, prior to the associated 
interrupt and discrete input being hardware and software c^nabled. The 
enable did not occur until TB2+4.5 seconds. The S-IB outboard engine 
out discrete input (DIM) was detected causing the expanded zero test to 
be used in accelerometer processing fo one computation cycle. S-IVB 
cutoff occurred at TCRR+566.96 seconds. The flight program correctly 
comipensated for this increase in thrust as acceptable end conditions were 
achieved . 

CASE #2 - THRUST AND MASS FLOW RATE IN BOTH STAGES 

This case was accomplished by simulating a 5®' decrease in the nominal 
thrust and mass flow rate in both the S-IB and S-IVP stages. As a result, 
fuel depletion of the S-IB stage occurrc-d at TB2-7. 470 seconds, 7. 937 
seconds later than nominal. In addition, the S-IVB stage burned 31. 738 
seconds longer than nominal with fuel depletion occurring at TCRR = 

640.339 seconds, 2,348 seconds before the calculated cutoff. Tlierefore, 
unacceptable end conditions were achieved. 

CASE #3 - HIGH STOP PMR (HPMR) FOR DURATION OF S-IVB 

This case was simulated by forcing a high propellant mixture ratio 
(HPMR) for the duration of the S-IVB burn. Due to the higher thrust 
and mass flow rate, S-IVB cutoff occurred at TCRR+582.832 seconds, 

1 7,828 seconds earlier than nominal. Satisfactory end conditions were 
achieved, indicating that the flight program correctly compensated for 
the high PMR , 
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CASE //4 . LOW STOP PMR (LPMR) FOR DURATION OF S-IVH 

This case was simulated by forcing a low propellant mixturi* ratio 
(LPMR) for the duration of the S-IVB burn. Due to the improper 
mixture ratio, the 3-IVB fuel depleted at approximately TGRR + 669. 043 
seconds. At fuel depletion, was equal to 5, 24 indicating that 5. 24 

seconds of additional burn time was required to reach cutoff. With the 
exception of the early depletion, the flight program correctly compensated 
for the low PMR, 


CASE #5 - ALL ACCELFR0MB:TER HARD FAILURE (A CHANNEL) 

In this case the A-acccleromete r channel in the X, Y and Z axes were 
frozen to zero at liftoff'. Whenever [AA“aI3[>2, the channel nearest 
the expected reading w-as used in computing velocity and position in 
that axis and the appropriate Mode Code* 24 bits were? s(*t. Since* ^A 
was forced to zero, the disagr(.*ement tost was failed w'ht*n |aH [>2. 
Whenever |.^A-^b| <3, the A channel reading was selected and the 
appropriate MC24 bits were reset. Therefore, when |^B|< 3, a zero 
reading was used in computing velocity and position in that axis. 

End conditions telemetered by the LVDC compared favor< bly wdth the 
desired end conditions. How'cver, ’’actual" end conditions indicat . by 
the 6D were perturbed sufficiently that the orbit attained was slightly 
undesirable. All flight sequencing was correct. 


CASE Hb - X-ACCELEROMETER HARD FAILURi: (BOTH CHANNELS) 

In the computation cycle following GRR, the X -accele romete r A and B 
channels were frozen to force* zero accel e* rome*te* r re adings, simulating 
failure conditions. The accelerometer zero test correctly de*tected tlu* 
zero readings as failure indications, and set bits 2, 3, and 23 in Mode- 
Code word 24. The SMC calculations were inhibited and the- bacliup 
acceleration, (F/M)c» was used to compute the velocity and position 
in the X-axis. 

Whenever the accelerometer zero test was disabled or whe n j^p-9v3^<2^, 
the zero acceleromf*te r readings in the X-axis were* accepted and were 
used in computing position and velocity in the X direction. Bits 2, 3 and 
23 of Mode Code 24 w'cn* res(*t and hit 1 0 of Mode Code 2S was set when 
the SMC calculations became active. 
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As a result of using the erroneous zero readings when the zero test 
was disabled or when |5p-9CP|<2® and using (F/M)^ during all other 
periods of flight, large navigation errors developed in the X direction. 

The X navigation errors caused slightly incorrect gravitational com- 
ponents to be used in the other axes thus causing small navigation 
errors in the Y and Z directions. As a result, the end condMions 
achieved were not suitable for comparison with nominal end conditions. 

S-IVB cutoff occurred at TGRR + 601.465 seconds, .804 seconds later 
than nominal. 

All sequencing was executed properly and there were no deviations from 
specifications. 


CASE m - Y-ACCELEROMKTER HARD FAILURE (l^OTH CHANNELS) 

In the computation cycle following GRR, the Y-accelerometer was 
frozen in both the A and R channels, resulting in zero readings. The 
accelerometer zero test correctly detected the zero readings as 
failure indications. The zero accelerometer readings in the Y-axis 
were rejected whenev<?r the accelerometer zero test was t nabled and 
1^ yaw|>2®. Bits 4, 5 and 1 9 of MC?A w-erc set, thf‘ SMC calculations 
were inhibited, and the (F/M)^ backup profile was used to calculate 
position and velocity in the Y direction. 

The zero accelerometer readings in the Y-axis were accepted and used 
in computing position and velocity in the Y direction whenever the 
accelerometer zero test was disabled or when | 0yaw|<2®. Bits 4, S 
and 1 9 of MC24 remained reset during the BML, 

Large navigation errors developed in the Y direction as a result of 
using the erroneous zero readings when the zero test was disabled or 
when |^yaw|<2®, ann using (F/M)c during all other periods of flight. 

The LVDC end conditions attained were good. The 61) end conditions 
were slightly perturbed as a result of the navigation errors, although 
they were still acceptable. This case df‘monstrated the capability of 
the flight program to handle a Y-accelerometc‘r hard failure and still 
attain acceptable end conditions, 

S-IVB cutoff occuried at TGRR + 600. 763 seconds which was near nominal 
cutoff time. All flight sequencing was correct. 


C-3 



! 


! 


CASE H8 - Z-ACCELEROMETER flARD FAILURE (BOTH CHANNELS) 

In thi5» caso, the Z-acceleromcter was failed to zt-ju in the comp, cycle 
lollovdng GRR. Both the A and B channels were frozen to force zero 
readings. 

The accelerometer zero test co»*rectly detected the Z-acceleromete r 
zero readings as failure indications. Whenever the accele romc^te r zero 
♦“est was enabled and the zero accelerometer readings in the 

Z-axis were rejected. The sign bit, bit 1 and bit 22 of MC24 were set, 
the SMC calculations were inhibited, and (F/M)c was correctlv substituted 
for F/M. The resultant acceleration component is correctly user} in 
the calculation of position and velocity in the Z direction. Whenever 
the accelerometer zero test w'as disabled or zero readinus 

in the Z-axis were accepted and the sign bit, bit 1 and bit 22 of MC24 
were reset. 

Large navigation errors developed in the Z direction as a result of 
using the erroneous zero readings wht*n the zero t(*st was disabled and 
when |0p[< 2^ and using (F/M)^ during all other periods of flight. 

The S-IV13 fuel depleted at TGRR*fb05. 817 seconds, with T3J equal to 
. 86 seconds. 


CASE il9 - ENGINE III OUT AT TH5 SECONDS 

Engine lost thrust at Tl + 5 seconds and was properly defected at 
that time. The tilt freeze interval, /.Tf, was correctly coruputed to be 
12.855 Seconds and was implemented at Tc + 30.417 seconds, with tilt 
arrest occurring at Tc**1 22. 475 seconds. S-IB fuel depLtion occurred 
at TGRR + 1 78. 867 seconds, 21. seconds later than nominal. The 
S-IVB stage depleted fuel at TGRK^r;27. 203. T3j at this time was 
approximately 3. 74, indicating that 3. 74 additional seconds of burn time 
would have been required to reach cutoff. The flight program prone rlv 
corrected for the engine out and performed properly up to fuel depletion. 


CASK no - ENGINE /i e> OUT AT LIFTOFF 

This case was accomplished by sin-iulating the failure* of S-IB engine 
K(j (inboard) at TB140.0 seconds. As a result, the tilt freeze inte rval, 
ATf, w'as computed to be 1 3. 875 seconds wdth tilt arrest. T^r* dating 
the boost major loop conimencirg at T1U41/6. 13, 10. 8 seconds late*r 
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than nominal. S-IB fuel clfph-tion occurred at TGRR + 178. 1 8, 20. > 
seconds later than nominal. S-IVB fuel d(‘pletion occurred at TCiRR^ 
626 69 seconds, with T3I“3, 83 seconds. All flight seque^ncing was 
correct. 


CASE #11 - ENGINE (14 OUT AT 40 SECONDS FROM LIFTOFF 

This case was accomplished by simulating the failure of S-IB engine 
#4 (outboard) at TB^*f40.03 seconds. Tilt arrest occurred during the 
boost major loop commencing at TBl+108. 02 seconds (tilt freeze 
interval, *Tf, was zero). S-IB fuel depletion occurred at TGRP -tl 73. 43 , 
which is 16.15 seconds later than nominal. S-IVB cutoff occurred at 
TGRR4620. 46 seconds, 19.8 seconds later than nominal. Acceptable 
end conditions were achieved. 

CASE #12 - ENGINES #1 AND OUT AT 100 SECONDS FROM LIFTOFF 

This case was accomplished by simulating tlu* failure* of S-IJi engines 
#1 (outboard) and #5 (inboard) at TBl fl00.0 > seconds. The tilt freeze 
interval, ATf, was calculated to be 0.0 and tilt arrest, T^j-, occurred 
at TGRR + 125. 34 seconds. S-IB fuel depletion occurred at TGRR4 
171, 996, 14.7 seconds later than nominal. The S-IVI^ engine cutoff 
occurred at TGRR.4^61 8. 50, 17,84 seconds later than nominal. The 
S-IVB burned only 3. 12 sc conds longer than noniinal due the two 
S-IB engines out. End conditions achieved were satisfactory. 

CASE #13 - FINE GIMBAL FAILURE, FLY ON BACKUPS 

This case was simulated by failure of the X, Y and Z fine gimbals so 
that the vehicle would fly using the backup gimbals. The flight program 
correctly responded to this condition, wuth S-IVB cutoff occurring only 
.08 second later than nominal at TGRR^f>00. 74. Proper flight or('grai>i 
response was demonstrated in that acceptable end conditions were 
noted with little change in vehieW* performance, 

CASE #14 - 42^ 6p BIAS, 41^ BIAS 

This case was sin^ulated by perturbing the pitch gimbal angle f* p) by 
1® and the no:.zle deflection (- by 2^. The flight program correctly 
responded to this condition with S-IVli cutoff occurring at TGRR--* OJ. ^3, 

2. 33 seconds later than nominal. Proper fPght prtjgran\ con'ip.it^t ion 
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of steering misalignment correction (SMC) terms was demonstrated in 
that acceptable end conditions were achieved, with the perturbation 
naving little effect on flight program performance. The pitch SMC 
terms were significantly larger than nominal. 


CASE ns - -2^ S BIAS, 6 BIAS 

P P 

This case was simulated by perturbing the pitch gimbal angle by -1® 

and the nozzle deflection (Bp) by -2®. The flight program correctly 
responded to this condition with S-IVB cutoff occurring at TGRR*f602. 86, 
2. 20 seconds later than nominal. Proper flight program computation of 
steering misalignment correction (SMC) terms was demonstrated in 
that acceptable end conditions v/ere achieved, with the perturbation 
having little effect on flight program performance. The pitch SMC terms 
were significantly larger than nominal. 


CASE #16 - +2^ 3,, BIAS, 41"^ 6 BIAS 

y y 

This case was simulated by perturbing the yaw gimbal angle (0y) +1^ 
and the yaw nozzle deflection {6y) +2°. As a result, fuel depletion of 
the S-IB stage occurred at TB2 = 6. 742 seconds, 0. 014 seconds earlier 
than nominal. In addition, the S-IVB stage burned 2. 339 seconds long r 
than nominal with cutoff occurring at TGRPv = 603. 008 seconds. However, 
the flight program correctly compensated for these biases as acceptable 
end conditions were achieved. 


CASE #17 - -2^ S,, BIAS, -1"^ 0 BIAS 

y y 

This case was simulated by perturbing the yaw gimbal angle (0 y) -1^ 
and the yaw nozzle deflection ( 3y) -2^. A.s a result, fuel depletion of 
the S-IB stage occurred at TB2 = 6. 752 seconds, 0. 024 seconds earlier 
than nomiiial. In addition, the S-IVB stage burned 3.408 seconds longer 
than nominal with cutoff occurring at TGRR = 6f^4. 068 seconds. However, 
the flight program correctly compensated for these biases as acceptable 
end conditions were achieved. 



CASE ns - S-IB ENGINE ffl ACTUATOR HARDOVER INBOARD AT 
SEVEN SECONDS FROM LIFTOFF 

This case was simulated by forcing the pitch and yaw actuators of 
engine O to a value of 8 degrees in a negative direction. As a result, 
fuel depletion of the S-IB stage occurred at TB2=6. 801 seconds, 0. 044 
seconds later than nominal. In addition, the S-IVB stage burned 1. 220 
seconds longer than nominal vdth cutoff occurring at TGRR = b01. 919 
seconds. However, the flight program correctly compensated for this 
failure as acceptable end conditions were achieved. 
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APPENDIX D 

END CONDITIONS COMPArUSON 
TABLE I 

PERFORMANCE CASE ERRORS 

Flight Azimuth" 45. 15 8° 
(Desired -Achieved) 


Parameter 

A Vrj, 

ARip 

A6 ^ 

A I 

AX 

Units 

M/S 

M 

Deg. 

Deg. 

Deg. 

Desired 






Values 

7818. 46 

6528178. 0 

0. 0 

51. 78 

156. 887 

Case 






1 

29 

-7. 64 

-. 0042 

-. 0024 

-0. 0036 

2 

S-IVB 

Fuel Depletion 




3 

. 186 

3. 46 

-. 00083 

-. 0027 

-. 0039 

4 

S-IVB 

Fuel Depletion 




5 

. 128 

28. 89 

. 0033 

. 0001 

0. 0 

5-6D- 

-11. 82 

-6445. 6 

-. 1726 

-. 0108 

-. 0066 

6 

. 068 

11. 38 

-.00016 

-. 0034 

-. 0053 

6-6D>:= 

8. 70 

11788. 4 

-. 2216 

-. 0082 

-. 0086 

7 

-. 093 

29. 26 

. 00013 

-. 0169 

-. 0261 

7-6D=:= 

-. 14 

60. 55 

. 00074 

-. 0317 

-. 0120 

8 

S-IVB 

Fuel Depletion 




00 

1 

o 

S-IVB 

Fuel Depletion 




9 

S-IVB 

Fuel Depletion 




10 

S-IVB 

Fuel Depletion 




11 

-. 122 

30. 36 

. 0029 

-.0006 

. 0010 

12 

. 043 

28. 5 

. 0034 

-. 0013 

. 0022 

13 

. 12 

35. 4 

. 0014 

-. 0006 

0011 

14 

-. 107 

43. 4 

. 0056 

. 0004 

. 0006 

15 

-. 065 

12. 73 

. 00014 

-. 0002 

-. 00045 

16 

-. 14 

35. 3 

. 003 

-. 001 

-. 002 

17 

-. 32 

37. 8 

. 003 

. 001 

. 002 

18 

. 08 

20. 1 

. 002 

. 001 

. 001 

^Accelerometer failure 

cases, 6D data included for 

comparison. 
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APPENDIX E 

UNCORRECTED DEVIATIONS 

ASTP-1 In TB2 if an accelerometer '^zero” reading {A of 0 or 1 bit) 

occurs near S-IB lECO, the accelerometer zero reading may 
fail the zero test even if the reading should be acceptable. 

If the SIB lECO occurs between the computation of the expected 
accelerometer change, Vp, and the computation of the thrust 
misalignment uncertainty in the estimated accelerometer 
change, Apo, the value for F /M could be changed between the 
two computations. This is due to F /M being set to a constant 
at lECO, Thus, the comparison of Vp, with A(-q, would not 
be valid, possibly resulting in the accelerometer reading 
incorrectly failing the zero test. 

ASTP-2 The Execute Generalized Maneuver DCS command may be enabled 

at a time different than Ts5-2905, 0 in TBS. The enable for this 
command is scheduled, in the Time Base S module, by adding 
TlDD'^ S- f2905. 0 seconds in TBS. This will be the 
correct time if the safing sequence is started after completion 
(full duration) of the LOX and LH 2 dumps specified in the S-I\'/ 
lU De-orbit DCS Command, This will not be T55-^'2905 if the 
safing sequence is started by one of the othiCr three conditions 
stated in Note 6 of the switch selector table: 

1 . 

2 . 

3 . 
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APPENDIX F 

NOMINAL SEOUENCL OF MAJOR EVENTS 
ASTP 45, 158 Degree Azimuth Nominal 

Event Nominal Time 

in Time Base 



(seconds) 

Guidance Reference Release 

TBO-l-0. 00 

Time Base 1 Initiated 

TBO + 17. 67 

Pitch and Roll Initiation 

TBl+8. 79 

Roll Maneuver Complete 

TBl + 57. 47 

Computer Switch Point 

TBl+99. 96 

Computer Switch Point ?'f2 

TBl + lOO. 17 

Computer Switch Point 3 

TBl + 119. 9h 

Tilt Arrest 

TB1-H28. 11 


(Tc + 129. 73) 

Time Base 2 Initiated 

TBl + 132. 87 

S-IB Inboard Engines Cutoff 

TB2+2. 97 

S-IB Outboard Engines Cutoff 

TB2+i).74 

Time Base 3 Initiated 

TB2 + 6. 74 

S-IVB Ullage Ignition 

TB3 + 1. Ob 

S-IB/S-IVB S(‘paration 

TB3 + 1. 26 

S-IVB Engine Start Sequence Initiated 

TB3+2. 67 

S-IVB Ullage Rockets Jettison 

TB3H3.27 

IGM Start 

TB3-f-34. 67 

Computer Switch Point -4 

TB3+41.96 

SMC Start 

TB3+60.07 

Computer Switch Point 5 

TB3+203. 6() 

Tu=0, Initiate PMRC 

TB3+328. 06 

Begin Chi-Bar Steering 

TB3+419. 74 

S-IVB Cutoff 

TB3+443. 38 

Time Base 4 Initiated 

TB3+443. 00 

Track Local Reference Start 

TB4 + 15. 1 1 


F-i 


1 1 

I 


Nominal Tim-' 
from GRR 
(second s ) 

0 . 00 
17. 67 
26. 46 
75. 14 
117. 63 
117. 84 
137. t-3 
145. 78 

150. 54 
153. 51 
157.28 
157.28 
158. 34 

158. 54 
159, 95 

170. 55 
191. 95 
199. 24 
217. 35 
3t.0. 94 
485. 34 
577. 02 
OOO. h< 

600. S'-. 

615, Q9 



